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ABSTRACT 


The  purpose  of  this  thesis  is  to  design  and  implement  a  concrete 
interface  generation  system.  The  concrete  interface  generator  is  a 
software  system  which  takes  a  formal  specification  as  input  and  gener¬ 
ates  the  specification  part  of  an  Ada  implementation  as  output.  Attri¬ 
bute  grammars  and  fourth-generation  language  tools  have  been  used  in 
the  implementation  of  this  system.  Spec,  a  formal  language  for  writing 
black-box  specifications  for  large  software  systems,  was  used  as  the 
input  for  the  concrete  interface  generation  system.  Ada  was  chosen  to 
be  the  computer  language  generated  by  the  system.  This  thesis  imple¬ 
ments  a  subset  of  the  Spec  language,  discusses  the  design  method¬ 
ology  used  in  its  implementation,  and  presents  guidelines  for  the 
mapping  of  Spec  to  Ada.  Included  is  a  listing  of  the  Spec  grammar,  the 
concrete  interface  generator  systems  source  listing,  a  sample  of  input 
used  to  test  the  system,  and  resulting  output. 
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I.  INTRODUCTION 


Due  to  the  ever-increasing  capability  of  computer  hardware  coupled 
with  the  ever-decreasing  cost  of  the  computer  hardware,  there  is  a  great 
pressure  being  placed  on  the  development  of  today’s  software  systems. 
The  software  systems  being  asked  for  in  today’s  environment  are  becom¬ 
ing  larger  and  much  more  complex.  Some  systems  being  developed  have 
more  than  a  million  lines  of  code.  A  software  development  organization 
numbering  100  individuals  may  take  years  to  complete  a  large  software 
project. 

Of  course,  the  development  cost  of  such  large  projects  is  going  to  be 
enormous.  Since  more  processes  are  being  automated  and  projects  are 
taking  longer,  the  pool  of  available  personnel  has  dwindled,  thus  driving 
wages  up. 

As  a  result  of  these  problems,  a  rapidly  growing  area  of  software 
engineering  is  the  development  of  tools  to  aid  in  the  software  develop¬ 
ment  process.  One  tool  developed  Berzins  [Ref.  1]  is  the  formal  specifi¬ 
cation  language  Spec.  Spec  is  used  for  writing  black-box  specifications 
for  components  of  software  systems  in  the  formal  specification  stage  of 
software  development.  Ihe  black-box  specifications  contain  the  major 
decisions  In  the  architectural  design  and  are  produced  by  highly  skilled 
software  designers. 
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Once  the  design  is  complete,  average  programmers  implement  these 
Spec  specifications.  Due  to  the  normal  human  factors  Involved,  the 
implementation  process  is  error  prone  and  time  consuming. 

To  help  solve  these  problems,  a  software  tool  is  needed  that  will 
reduce  errors  and  decrease  the  time  required  to  implement  formal  speci¬ 
fications.  This  thesis  centers  on  the  design  and  implementation  of  a 
concrete  interface  generation  S3rstem  that  would  automate  part  of  the 
implementation  process. 

A.  OBJECTIVES 

This  thesis  extends  the  application  of  attribute  grammars  and 
fourth-generation  language  tools  to  Include  production  of  a  concrete 
interface  generation  system.  The  system  is  created  by  developing  a 
source  program  for  the  fourth-generation  language  tool  Kodiyak.  The 
source  program  is  compiled  by  Kodiyak,  which  generates  the  desired 
system  (see  Figure  1.1).  The  design  methodology  and  guidelines  for 
producing  concrete  Interfaces  are  discussed  in  Section  B  of  Chapter  111. 


Figure  1.1.  Sjstem  Creation 


The  concrete  interface  generator  contemplated  for  this  research  is  a 
software  system  vdiich  takes  a  formal  specification  as  input  and  gener¬ 
ates  the  Ada  specification  as  output  (see  Figure  1.2).  Once  the  concrete 
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interface  generation  system  has  been  created,  it  does  not  interact  with 
Kodlyak. 


Figure  1.2.  Syttem  Use 


The  concrete  interface  generation  system  will  offer  software  engi¬ 
neers  a  cost-effective,  timely,  and  efficient  means  to  generate  Ada  specifi¬ 
cations.  Many  man-hours  will  be  saved  as  automatic  generation  replaces 
manual  methods.  The  concrete  interface  generator  will  also  greatly 
reduce  the  number  of  errors  inherent  in  the  human  process  of  coding  the 
Ada  specifications. 

B.  RESEARCH  QUESTIONS 

There  are  two  principal  research  questions  for  this  thesis.  First, 
what  are  the  basic  concepts  of  and  the  theoretical  foundations  for  design 
and  implementation  of  a  concrete  interface  generator  using  attribute 
grammars  and  fourth-generation  language  tools? 

Second,  what  are  the  issues  associated  with  designing  and  imple¬ 
menting  a  concrete  Interface  using  an  attribute  grammar  and  fourth- 
generation  language  tools?  Is  it  a  feasible  means  of  developing  a  software 
tool  such  as  a  concrete  interface  generator? 
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C.  ORGANIZATIO:  F  STUDY 

The  tools  used  tc  create  the  concrete  interface  generation  system  are 
described  in  Chapter  II.  Included  are  discussions  of  Spec,  attribute  gram¬ 
mars,  the  Kodiyak  Application  Generator,  and  several  software  tools  pre¬ 
viously  developed. 

The  design  and  implementation  are  presented  in  Chapter  III.  Design 
methodologies,  including  the  use  of  translation  templates  and  attribute 
dependency  diagrams,  are  discussed. 

Conclusions  are  presented  in  Chapter  IV,  which  also  discusses  sug¬ 
gestions  for  improvement  of  the  concrete  interface  generation  system, 
how  the  design  was  influenced  by  Kodiyak's  limitations,  and  what  exten¬ 
sions  to  the  application  generator  would  be  useful  when  developing  soft¬ 
ware  tools. 
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n.  BACKGROUND 


The  following  discussion  describes  the  Spec  grammar  used  in  this 
research,  attribute  grammars  in  general,  the  Kodiyak  application  genera¬ 
tor.  and  two  previous  tools  developed  using  these  components.  The  Kodi¬ 
yak  application  generator  Is  the  software  tool  actually  used  to  create  the 
concrete  interface  generator.  In  order  for  Kodiyak  to  perform  its  function, 
a  grammar  of  the  language  to  be  parsed  (Spec)  must  be  annotated  with 
attributes  that  generate  the  required  structures  of  the  desired  output 
language  (Ada). 

A.  8PBC-A  FORBCAL  8PBC1F1GATION  LANGUAGE 

Spec  is  a  formal  language  developed  to  make  the  process  of  describ¬ 
ing  components  of  large  software  systems  more  efficient  and  the 
components  themselves  less  ambiguous  for  implementation.  Black-box 
specifications  are  developed  to  describe  the  interfaces  for  each  module  of 
the  software  system  being  developed.  Discussion  of  the  event  model  and 
the  Spec  language  extracted  from  Reference  2  follows.  Appendix  A  con¬ 
tains  a  listing  of  the  grammar  for  the  Spec  language  used  in  this 
research. 

1.  Event  Model 

The  event  model  is  the  semantic  basis  for  Spec.  The  event  model 
uses  four  primitives:  modules,  messages,  events,  and  alarms.  A  module 
is  a  black  box  that  Interacts  with  other  modules  by  sending  and  receiving 
messages.  A  message  is  a  data  packet  sent  firom  one  module  to  another. 
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An  event  occiars  instantaneously  when  a  message  is  received  by  a  module 
at  a  particular  time.  An  alarm  defines  a  particular  time  in  a  module  at 
which  temporal  events  will  be  triggered. 

a.  Modules 

Modules  are  used  to  model  software  components.  They  are 
the  basic  building  blocks  of  Spec.  You  specify  a  module's  behavior  by 
describing  its  interface,  which  consists  of  the  set  of  stlmuU  (events)  it  rec¬ 
ognizes  and  their  associated  responses  (sets  of  events).  All  interactions 
must  Involve  explicit  message  transmissions.  There  are  five  kinds  of 
modules  in  Spec.  The  three  most  often  used  are: 

(1)  Functions.  A  function  has  no  memory  (is  Immutable), 
so  its  behavior  is  Independent  of  the  past.  Completely  specified  function 
modules  calculate  single-valued  mathematical  functions,  while  incom¬ 
pletely  specified  function  modules  can  behave  nondetermlnistically.  An 
example  Spec  function  is  shown  in  Figure  2. 1  [Ref.  1]. 

(2)  Machine.  A  machine  does  have  internal  memory  (is 
mutable)  so  its  behavior  does  depend  on  its  past  interactions.  The  behav¬ 
ior  of  a  machine  module  is  described  in  terms  of  a  conceptual  model  of 
its  state  using  a  finite  set  of  state  variables.  State  changes  can  only  occur 
at  events.  See  Figure  2.2  [Ref.  1). 

(3)  Types.  A  type  module  defines  an  abstract  data  type. 
The  definition  must  contain  a  value  set  and  a  set  of  operations  on  the 
value  set.  Types  can  be  mutable  or  immutable.  An  immutable  type  has  a 
fixed  value  set.  and  the  operations  of  an  Immutable  type  cannot  change 
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FUNCTION  square_root{ precis ion: float  SUCH  THAT  precision  >  0.0} 
MESSAGE (x:  float) 

WHEN  X  >-  0.0 

REPLY (y:  float) 

WHERE  y  >  0.0,  approximates (y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  imaginary_square_root 
CONCEPT  approximates (rl  r2:  float) 

VALUE (b:  boolean) 

WHERE  b  <«•>  abs(rl  -  r2)  <■  abs(r2  *  precision) 

END 

Figure  2.1.  Example  of  a  Spec  Function 


MACHINE  sender 
STATE  (data ;  sequence  ( bloc]c ) ) 

INVARIANT  true 
INITIALLY  data-[  ] 

MESSAGE  send(file:  sequence (bloc)c}) 

WHEN  length (file)  >  0 

SEND  first  (b:  bloc)c)  TO  receiver  WHERE  b  -  filed) 

TRANSITION  data  -  file 
OTHERWISE  REPLY  EXCEPTION  eng)ty_file 

MESSAGE  echo(b:  bloc)c) 

WHEN  b  ■■  datad)  (  length  (data)  >  1 
SEND  next(bl:  bloc)()  TO  receiver  WHERE  bl  -  data[l] 

TRANSITION  *data  -  b  I  I  data 
WHEN  b  <"  data[l)  «  length  (data)  -  1 
SEND  done  TO  receiver 
SEND  done  TO  sender 
TRANSITION  data  -  (  ] 

OTHERWISE  SEND  retransmit  (b2 :  bloc)c)  TO  receiver  WHERE  b2  >  datad) 
MESSAGE  done 

TRANSACTION  transfer  *  send;  DO  echo  OD;  done 
END 

Figure  2.2.  Example  of  a  Spec  Blachine 
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the  properties  of  the  individual  type  instances  (see  Figure  2.3  (Ref.  1]).  A 
mutable  type  can  create  and  destroy  type  instances  with  internal  states 
and  can  provide  operations  for  changing  them. 


TYPE  Char 

INHERIT  equality {char) 

INHERIT  total_order{char) 

MODEL (code:  nat)  —  ASCII  codes 

INVARIANT  ALL(c:  char  ::  ()  <-  c.code  <-  127) 

MESSAGE  create (n:  nat)  —  literal  'a'  «  create (97)  and  so  on 
WHEN  0  <-  n  <-  127  REPLY (c:  char)  WHERE  c.code  -  n 
OTHERWISE  REPLY  EXCEPTION  illegal_code 

MESSAGE  ordinal (c:  char)  REPLY (n:  nat) 

WHERE  n  c.code 

MESSAGE  equal (cl  c2:  char)  REPLY (b:  boolean) 

WHERE  b  <->  (Cl. code  -  c2.code) 

CONCEPT  letter (c:  char)  VALUE (b:  boolean) 

WHERE  b  <->  (C  IN  ('a'  ..  'z']  i  C  IN  ['A'  ..  'Z']) 

CONCEPT  digit (c:  char)  VALUE(b:  boolean) 

WHERE  b  <->  c  IN  ('0'  ,.  ' 9' 1 

END 


Figure  2.3.  Spec  Example  of  a  Type 
b.  Messages 

Messages  are  used  to  model  abstract  interactions.  These 
interactions  can  be  realized  as  procedure  calls,  returns  from  a  procedure. 
Ada  rendezvous,  etc.  Each  message  has  four  attributes:  the  origin  (who 
sent  the  message),  the  name  (used  to  identify  the  service  requested  by  a 
normal  message  or  the  exception  condition  determined  by  an  exception 
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message),  a  sequence  of  data  values  (either  inputs  or  results),  and  condi¬ 
tion  (either  normal  or  exception).  The  origin  of  a  message  is  the  event  or 
alarm  that  caused  the  message  to  be  sent.  The  reply  is  sent  to  the  mod¬ 
ule  that  sent  the  stimulus,  which  can  be  determined  from  the  message’s 
implicit  origin  attribute  (a  feature  of  the  event  model). 

c.  Events 

The  behavior  of  a  system  consists  of  a  set  of  events.  Each 
event  is  uniquely  identified  by  three  associated  properties:  a  module,  a 
message,  and  a  time.  “Time"  corresponds  to  the  time  at  which  the 
module  received  a  message. 

An  event  can  be  classified  as  reactive  or  temporal.  A  reac¬ 
tive  event  is  an  event  which  occurs  in  response  to  an  external  stimulus, 
such  as  the  user  initiating  a  response  from  the  system.  A  temporal  event 
occurs  when  a  regularly  scheduled  or  planned  event  (e.g.,  an  alarm)  initi¬ 
ates  an  internal  stimulus  which  requires  a  response  from  the  system. 

d.  Alarms 

Each  alarm  consists  of  a  module,  a  message,  and  a  time, 
but  an  alarm  causes  the  module  to  send  a  message  to  itself  at  the  given 
time.  Each  module  has  a  clock  that  measures  local  time  which  is  used  by 
the  event  model  to  control  events  that  must  happen  at  specific  times 
(e.g.,  at  3:(X)  a.m.  every  Sunday). 

2.  Some  Other  Components  of  Spec 

CL  D^nitUms  and  Instance  Modules 

Definitions  are  a  module  type  used  to  declare  concepts  that 
are  necessary  to  explain  the  system  being  described.  They  provide  access 
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to  widely  shared  concepts  needed  by  various  modules.  Definition  mod¬ 
ules  can  contain  only  concept  definitions. 

Instance  modules  are  used  to  maJce  an  instance  or  partial 
instantiation  of  generic  modules  and  for  making  interface  adjustments  to 
reusable  components  by  hiding  or  changing  some  names. 

b.  Concepts 

The  purpose  of  concepts  is  to  help  decompose  the  speci¬ 
fication  into  manageable  units.  Concepts  represent  properties  that 
describe  the  system’s  intended  behavior.  In  the  square-root  example, 
shown  in  Figure  2.1,  the  concept  “approximates’’  defines  what  you  mean 
by  “a  sufficiently  accurate  approximation*  in  terms  of  the  generic  psu  am- 
eter  precision. 

c.  Semantic  Issues 

There  are  many  semantic  Issues  (such  as  scoping  rules, 
naming  constraints,  and  type  constraints)  in  the  Spec  language  that  will 
lot  be  discussed  here.  More  information  concerning  these  issues  may  be 
f(  id  in  References  1  and  3. 

B.  ATTRIBUTB  ORAIOIIARS 

Attribute  grammars  were  .uroduced  by  Knuth  when  he  built  upon 
the  idea  of  defining  semantics  by  associating  synthesized  attributes  with 
each  non-terminal  symbol  and  associating  corresponding  semantic  rules 
with  each  production  [Ref.  4].  Knuth  showed  that  inherited  attributes  are 
useful  in  the  cases  where  part  of  the  meaning  of  a  given  construction  is 
determined  by  the  context  in  which  it  is  used. 
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The  development  of  an  attribute  grammar  begins  with  a  context-free 
grammar.  Each  grammar  S5rmbol  is  then  assigned  a  set  of  attributes 
which  are  divided  into  two  subsets:  Inherited  attributes  and  synthesized 
attributes.  Picture  the  node  of  a  grammar  symbol  in  the  parse  tree  as  a 
record  with  fields  for  holding  information,  then  each  attribute  corre¬ 
sponds  to  one  of  those  fields  as  in  Figure  2.4. 

The  greatest  use  of  attribute  grammars  has  been  for  translating  one 
language  to  another.  Specifically,  they  are  used  to  develop  compilers  and 
ccmpilers-compllers  (application  generators),  and  for  translating  gram¬ 
mar  specifications  into  executable  code,  such  as  the  work  presented 
here.  Attribute  grammars  are  extremely  well  suited  to  the  development  of 
these  tools  because  they  are  easily  modified  when  extensions  are  added 
and  the  attribute  equations  are  independent  of  each  other. 

C.  KODITAK  APPUCATION  GENERATOR 

The  Kodiyak  Application  Generator  is  a  language  designed  for  con¬ 
structing  translators  IRef.  5).  It  is  modeled  after  Knuth’s  descriptions  of 
attributed  grammars.  The  language  includes  facilities  for  describing  a 
lexical  scanner,  an  LALR  (1)  grammar,  and  attribute  definition  equations 
[Ref.  6). 

Kodiyak  integrates  the  functions  of  the  I£X  [Ref.  7]  analyzer  genera¬ 
tor.  the  YACC  [Ref.  8]  parser  generator.  an  J  the  code  necessary  to  com¬ 
pile  the  *C"  language  code  into  executable  code.  Kodiyak  lets  the  designer 
work  in  terms  of  equations  defining  attribute  values,  rather  than  with 
fragments  of  “C"  code,  as  necessary  vriien  using  YACC  directly.  Kodiyak 
takes  care  of  the  interface  details  so  the  user  is  not  bothered  with  them. 
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Figure  2.4.  Grammar  Symbol  and  Attribute  Relationehip 
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The  discussion  that  follows  was  extracted  from  Ref.  6  and  provides 
only  that  information  required  to  understand  the  code  in  this  research. 
Complete,  detailed  information  can  be  obtained  from  References  6  and  9. 

1.  Format 

The  Kodiyak  program  has  three  sections.  The  first  section 
describes  the  features  of  the  lexical  scanner  which  is  used  to  translate 
the  source  text  into  tokens,  establish  operator  precedence  and  declare 
assocladvltles  for  those  tokens.  The  second  section  names  the  attributes 
associated  with  each  grammar  symbol  and  defmes  their  types.  The  third 
section  describes  the  grammar  and  the  attributed  equations  which  define 
the  semantics  of  the  translation.  These  three  sections  in  a  Kodiyak  pro¬ 
gram  are  separated  by  a  doable  percent  symbol  ('*%%*')  on  a  line  between 
each  section. 

2.  Comments 

The  exclamation  point  rt”)  is  used  to  start  a  comment  which 
continues  to  the  end  of  the  line  it  is  located  on.  A  comment  may  begin 
anywhere  on  the  line. 

3.  Lexical  Scanner  Section 

The  prlmaxy  function  of  statements  in  this  section  is  to  specify 
the  terminal  symbols  of  the  grammar  and  how  input  text  is  to  be  trans¬ 
formed  to  these  symbols.  The  secondary  function  is  to  specify  a  set  of 
operator  precedence  to  be  used  in  conjunction  with  the  grammar.  An 
example  of  typical  statements  found  in  this  section  are  shown  in  Figure 
2.5.  The  most  common  form  of  the  basic  token  definition  is: 

TERMINAL_NAME  :REGULAR_EXPRESS10N 
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The  keyword  "%define’*  Introduces  the  definition  of  a  class  of 
terminal  symbols.  For  example  DIGIT,  in  Figure  2.5,  is  defined  to  be  a 
single  ASCII  character  between  “0"  and  “9." 

Terminal  symbols  can  be  described  using  the  defined  characters 
class  symbols.  For  example  the  terminal  symbol  “NUMBER”  shown  in 
Figure  2.5,  is  described  using  the  previously  defined  symbol  “DIGIT."  The 
braces  (“{ }")  are  used  to  Indicate  a  previously  defined  symbol. 

! Lexical  Section 

! Lexical  definitions 

Idefine  OXOIT  : [0-9] 

Idefine  ALFA  : [a-zA-Z] 

Idefine  ALFANUM  : [a-zA-z_0-9] 

!  Tezminal  names  described  using  lexical  definitions 

NUMBER  :(OXGXT}-»- 

NAME  : [ALPHA] (ALPHANUM)* 

!  Operator  precedence 

Heft  '  + 

Heft  V 

Figure  2.5.  Sample  Lexical  Definitions 

An  important  part  of  the  lexical  section  is  the  resolution  of 
ambiguities  found  in  the  input  text  that  match  more  than  one  regular 
expression  in  the  program.  When  this  occurs,  two  rules  are  applied  to 
resolve  the  conflict.  The  first  rule  is  that  v«iien  text  matches  more  than 
one  regular  expression,  the  regular  expression  which  matches  the 


14 


greatest  number  of  characters  is  applied.  The  second  rule  is  that  if  the 
input  text  matches  more  than  one  token,  the  rule  which  occurs  first  has 
precedence. 

Conflicts  between  productions  in  the  grammar  are  resolved  by 
operator  precedence  declarations.  Operator  precedence  declarations 
begin  with  %left,  %rlght.  or  %nonassoc.  The  keyword  “%left"  in  Figure 
2.5  implies  left  associativity  for  the  line  (e.g..  6  4  7  associates  as 
(6  +  4)  +  7).  The  operators  with  the  weakest  binding  power  are  listed  first. 
Operators  on  the  same  line  have  equal  precedence. 

4.  Attribute  Deelaratlon  Section 

The  attribute  declarations  section  consists  of  attribute  declara¬ 
tions  for  all  non-terminals  and  named  terminals  In  the  program.  There 
are  two  simple  data  types  for  attributes:  strings  and  integers.  The  data 
type  for  each  attribute  of  each  terminal  or  non-terminal  must  be  declared 
in  this  section,  as  in  Figure  2.6. 

Named  terminal  symbols  (e.g.,  “AND”  in  Figure  2.6)  are  permit¬ 
ted  two  special  predefined  attributes  that  are  provided  to  the  program¬ 
mer.  The  first  is  ”%text.“  udilch  is  a  string  type  and  is  Initialized  to  the 
input  text  matched  by  the  terminal  symbol.  The  second  is  ”%llne,''  which 
is  an  integer  type  and  is  Initialized  to  the  line  number  of  the  Input  text  on 
which  the  matching  text  occurred. 
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%%  !  Separates  lexical  scanner  section  from  attribute  declarations 
!  section. 

!  Attribute  declarations 


module_header{ 

name  : string; 

generic_parameters  : string; 

}; 

messages ( 

formal_parameters  : string; 
exceptlon_declaratlons  : string; 
1; 

message ( 

formaljparameters  : string; 
return_type  : string; 
except lon_decla rat Ions  : string; 
}; 

ANDi 

Itext  : string; 

); 


%l  !  Separates  attribute  declarations  section  from  attribute 
!  grammar  section. 


Figure  2.6.  Sample  Attribute  Declarations 

5.  Attribute  Qramiiiar  Section 

The  attribute  grammar  section  defines  the  syntax  and  seman¬ 
tics  of  the  translation.  It  consists  of  a  set  of  Bachus-Naur  Form  (BNF) 
rules  and  sets  of  equations  defining  attributes.  The  rule  syntax  Is  shown 
in  Figure  2.7. 
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non_terminal  ;  symbol-l  symbol-2  symbol-3 
{ 

!  Attribute  equations  go  here. 
_ U _ 

Figure  2.7.  Syntoz  of  Kodlyak  Rules 

The  rule  In  Figure  2.7  means  the  non- terminal  can  be  recog¬ 
nized  if  the  symbols  listed  after  the  '‘f  appear  in  the  sequence  shovm.  If 
the  non-terminal  is  recognized,  the  attribute  equations  for  those  symbols 
will  be  evaluated. 

Itodiyak  includes  additional  functions  of  potential  value  that 
have  not  been  discussed  here.  Explanations  of  these  functions  may  be 
found  in  Reference  6. 

6.  Using  Sodlyak 

The  Kodlyak  Input  program  must  be  stored  in  a  file  named  with 
a  “.k'  suffix  (e.g..  program_name.k).  The  command  to  invoke  Kodlyak  is 
*k  program_name”  where  ‘‘program.name.k*  is  the  input  program  to  be 
ccHnpiled.  Once  Kodlyak  has  started  running,  it  creates  and  then  deletes 
several  files  during  its  processing.  When  it  has  finished  processing,  the 
input  program  is  still  pritsent  along  with  three  other  newly  created  files. 
The  object  code  wiU  be  located  in  the  file  named  ‘‘program.name,”  compi¬ 
lation  statistics  are  stored  in  “program.name.stats.**  and  the  file 
“program.name.z*  will  contain  a  symbolic  listing  of  the  parser  tables  and 
other  diagnostic  information. 
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D.  TOOLS  IBfPL£BfENTED  WITH  ATTIUBUTBGRABCMAR  TOOLS 

Some  previous  applications  of  the  Kodiyak  Application  generator  are 
described  here. 

1.  Specification  Language  Type  Checker 

The  purpose  was  to  Implement  a  language-dependent  type 
checker  for  the  specification  language  Spec.  The  code  to  create  this  tool 
is  written  entirely  as  an  attribute  grammar  and  then  compiled  using  the 
Kodiyak  Application  Generator,  producing  the  executable  code  [Ref.  10]. 

2.  Language  Translator  For  The  Computer-Aided  Prototyping 

System  (CAPS) 

The  PSDL  translator  translates  prototype  specifications  written 
in  the  Prototype  Description  Language  (PSDL)  into  Ada.  The  design  of  the 
PSDL  language  translator  used  a  “template  translation  methodology** 
developed  by  the  author  [Ref.  11)  that  is  used  in  the  research  presented 
here.  These  templates  are  used  to  derive  the  attribute  equations  that 
form  the  core  of  the  Kodiyak  source  files. 

3.  Tost  Result  Classifier 

The  test  result  classifier  is  a  tool  developed  to  parti;  Ty  auto¬ 
mate  the  testing  puase  of  i  large  software  development  project.  The  test 
result  classifier  repeat'  .y  calls  a  program  module  and  reports  the  cases 
when  the  results  of  the  call  do  not  conform  to  the  specification  of  the 
module  [Ref.  12).  Spec,  Kodiyak.  and  Ada  were  used  in  the  development 
of  the  test  result  classifier. 

4.  Specification  Pretty  Printer 

A  pretty  printer  is  a  software  tool  used  to  format  expressions  of 
a  formal  language  in  a  consistent  manner  so  they  are  easier  to 


18 


understand  and  read.  The  specification  pretty  printer  is  designed  to  cor¬ 
rectly  format  the  formal  specification  language  Spec  [Ref.  13).  Kodiyak 
was  used  to  generate  the  specification  pretty  printer. 
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m.  DBSCRIPnON  OP  THE  DESIGN  AND  IBfPLEBSENTATION 


This  chapter  explains  the  design  and  implementation  of  the  concrete 
interface  generator.  The  concrete  interface  generation  system  is  a  soft¬ 
ware  tool  designed  to  automatically  generate  Ada  specifications  from  a 
formal  specification  language. 

To  avoid  confusion  throughout  this  chapter,  Spec  keywords  will  be 
written  in  uppercase  (e.g..  MESSAGE).  The  curly  braces  **{ }”  will  be  used 
to  denote  an  attribute  name,  such  as  {name}. 

A.  THE  PROBLEM 

The  development  of  a  large  software  system  is  a  time-consuming, 
error-prone  process.  Most  often,  the  design  phase  of  the  development 
process  is  rushed  so  the  coding  phase  can  begin.  However,  the  design  is 
probably  the  most  Important  part  of  the  development  process.  If  there 
were  a  tool  to  automatically  generate  some  of  the  actual  code,  more  time 
could  be  spent  in  the  design  phase. 

1.  Why  Ada  Was  Chosen 

Ada  was  chosen  to  be  the  target  programming  language  for  the 
concrete  interface  generator  for  several  reasons.  One  reason  is  the  U.S. 
Department  of  Defense  (DOD)  directive  that  Ada  is  to  be  used  in  develop¬ 
ing  software  systems  for  DOD  (Ref.  14].  Other  reasons  are  related  to  the 
design  goals  of  the  language  itself.  Ada  was  designed  to  support  abstrac¬ 
tion.  information  hiding,  and  modularity,  which  makes  it  very  compatible 
with  Spec. 
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2.  Packages 

One  of  the  basic  program  units  in  Ada  is  the  package.  Packages 
are  used  to  define  a  collection  of  logically  related  subprogram  units 
(procedures  and/or  functions),  type  declarations,  and  associated  opera¬ 
tions.  A  complete  Ada  package  is  divided  into  two  parts: 

1.  Specifications- The  package  specification  gives  the  compiler  the 
information  it  needs  for  type  checking,  storage  allocation,  and  gen¬ 
erating  calls  for  resources  defined  in  the  package.  It  should  also 
give  the  user  Information  about  what  the  package  does,  but  this  is 
accomplished  via  informal  comments  rather  than  via  formal  Ada 
structures. 

2.  Body- The  body  contains  the  details  of  the  package,  such  as  the 
procedures,  functions,  etc.  to  actually  implement  the  abstract  idea 
described  by  the  Spec. 

Figure  3.1  shows  a  complete  Ada  package.  Since  packages  are 
probably  the  most  frequently  used  program  units  in  Ada.  any  software 
tool  designed  to  generate  Ada  code  would  be  expected  to  generate  the 
package  construct.  The  package  program  unit  is  Included  in  the  current 
implementation  of  the  concrete  interface  generator. 

3.  Limitations  of  this  Implementation 

Only  a  subset  of  the  Spec  grammar  has  been  implemented  in 
this  version  of  the  concrete  Interface  generator  system.  The  implementa¬ 
tion  presented  here  includes  Spec  fimctions  and  generates  Ada  specifica¬ 
tions  for  packages,  generic  functions,  and  non-generic  functions.  The 
current  implementation  does  not  include  Spec  MACHINES  or  TYPES, 
although  the  current  design  covers  these  cases. 
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generic 

precision:  float; 
package  sqiiare_rootjpkg  is 

function  square_root  (x;  float)  return  float; 
iniaginary__square_root:  except! 
end  square_rootjpkg; 

package  body  square_rootjpkg  is 

function  square^root  (x:  float)  return  float  is 
z:  float  :<■  x; 

tolerance;  float  x  *  precision; 
begin 

if  X  <  0.0  then 

raise  iinaginary_square_root; 
end  if; 

while  (abs(z  *  z  *  x)  >  tolerance)  loop 

Bound:  floor (abs(z  •  x  /  z)  /  tolerance), 
z  (z  +  X  /  z)  *  0.5; 
end  loop; 
return  z; 
end  square^root; 
end  8quare_rootj?kg; 


package 

specification 


package 

body 


Figure  3.1.  Complete  Ade  Peekage 

The  implementation  requires  that  the  Mser  provide  the  following 
resources  to  facilitate  the  creation  and  use  ot  d  Ada  specification  pro¬ 
duced  by  the  concrete  interface  generation  system. 

1.  Correct  Spec  input 

2.  Type  declarations  for  types  contained  in  the  Spec 

Correct  Spec  input  Is  needed  because  the  system  does  not  have  an  error- 
checking  capability.  The  user  also  supplies  Ada  packages  containing  the 
declarations  of  all  data  types  and  any  required  I/O  routines  for  those 
types. 
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The  Spec  description  of  the  generic  square_root  function  is 
shown  in  Figure  3.2.  The  Ada  function  “square_root"  shown  in  Figure  3. 1 
is  implemented  based  on  the  Spec  description  of  the  required  abstract 
interface,  in  accordance  with  Spec  concrete  interface  conventions  (Ref.  IJ. 
An  example  of  a  procedure  using  “square_root_pkg"  is  shown  in  Figure 
3.3.  The  procedure  “Main"  provides  all  the  declarations  and  I/O  routines 
needed  by  the  package. 


FUNCTION  square__root {precision: float  SUCH  THAT  precision  >  0.0} 
MESSAGE (x:  float) 

WHEN  X  >-  0.0 

REPLY (y:  float) 

WHERE  y  >  0.0,  approximates (y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  imagiriary_square_root 
CONCEPT  approximates (rl  r2:  float) 

VALUE (b:  boolean) 

WHERE  b  <->  ab8(tl  -  r2)  <■  abs(r2  *  precision) 

END 


Figure  3.2.  Spec  Description  of  square.root  Function 


with  square_root_plcg,  text_io; 
use  text_io; 
procedure  main  is 

pac)ca^e  sg_rt  is  new  square_root_p)cg (float' epsilon) ; 
pac]cage  f_io  Is  new  float_io  (float) ; 
use  scL>ft,f_io; 
s,  y:  float; 
begin 

put ("input  value:  ") ; 
get(x) ; 

y  :-  8quare_root (x) ; 
put (y) ; 
end  main; 


Figure  3.3.  Procedure  Using  •quare.root.pkg 
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4.  Intended  Usage 

The  purpose  of  the  concrete  interface  generation  system  is  to 
reduce  the  time  needed  to  implement  a  large  software  system  after  it  has 
been  formally  specified  with  Spec.  Since  the  Ada  code  is  automatically 
generated  the  number  of  coding  errors  will  be  greatly  reduced. 

B.  THE  DESIGN 

1.  Mapping  Spec  to  Ada 

General  rules  for  generating  concrete  interface  specificat  ^ns  in 
Ada  CO'  espondlng  to  an  abstract  architectural  design  expressed  i  Spec 
were  o. /eloped  in  the  book  Software  Er^ineertng  with  Abstractions  by 
Berzins  and  Luqi  [Ref.  5].  MESSAGE  is  the  key  construct  of  Spec  that 
determines  which  Ada  program  unit  or  subprogram  unit  the  Spec  module 
will  be  translated  into.  The  number  of  output  parameters  and  the  Spec 
constructs  associated  with  the  message,  such  as  REPLY  and  GENERATE, 
greatly  affect  the  end  result.  The  rule  that  applies  to  the  FUNCTION 
“square.root”  is  as  follows: 

A  message  with  a  REPLY  containing  exactly  one  data  component  and 
without  any  TRANSITION  clauses  corresponds  to  an  Ada  function 
with  an  “in”  parameter  for  each  component  of  the  MESSAGE  and  a 
“return”  corresponding  to  the  single  data  component  of  the  REPLY. 
[Ref.  11 

Once  the  program  unit  has  been  determined,  details  of  mapping 
Spec  to  Ada  are  driven  by  the  Spec  grammar.  Each  word  of  the  Spec 
module  provides  information  to  determine  the  completed  Ada 
specification. 
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There  are  two  other  general  rules  for  the  mapping  of  Spec  to 
Ada  not  implemented  here.  These  rules  determine  the  type  of  Ada  proce¬ 
dure  into  which  the  Spec  will  be  translated.  When  the  MESSAGE 
Includes  a  Spec  GENERATE,  the  following  rule  applies: 

A  message  with  a  GENERATE  corresponds  to  a  generic  procedure 
with  a  single  generic  procedure  parameter.  The  generic  parameter 
represents  the  body  of  the  loop  to  be  driven  by  the  generator,  and 
takes  one  “In"  parameter  corresponding  to  the  elements  of  each 
sequence  to  be  generated.  The  state  variables  of  the  loop  correspond 
to  nonlocal  variables  of  the  actual  procedure  bound  to  the  generic 
parameter.  (Ref.  1) 

If  the  Spec  construct  does  not  correspond  to  either  of  the  two  cases 
described  above,  the  following  rule  will  apply: 

A  message  that  does  not  match  the  previous  two  cases  corresponds 
to  an  Ada  procedure  with  an  “in"  parameter  for  each  component  of 
the  MESSAGE  and  an  “out"  parameter  for  each  component  of  the 
REPLY,  if  there  is  one.  (Ref.  11 

Additional  alternatives  to  these  rules  can  be  introduced  by  Spec  pragmas 
(Ref.  1].  These  additional  alternatives  are  not  supported  by  the  current 
version  of  the  concrete  interface  generator. 

2.  Translation  Templates 

A  translation  template  is  a  schematic  representation  of  the  out¬ 
put  desired  from  the  translation  process,  which  in  this  case  is  an  Ada 
program  unit.  Translation  templates  are  used  for  organizing  and  naming 
the  attributes  needed  for  the  implementation.  The  attribute  names  iden¬ 
tify  slots  to  be  filled  by  the  attribute  grammar.  There  are  two  steps  in 
building  the  templates: 

1.  Determine  the  fixed  portions  of  the  program  unit. 
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2.  Determine  and  name  the  computed  portions. 

The  fixed  portions  of  the  template  consist  of  Ada  reserved 
words,  lexical  elements,  separators,  and  delimiters.  These  are  shown  in 
plain  type  in  Figure  3.4.  The  portions  of  the  program  that  must  be 
determined  using  attribute  equations  are  given  names  and  analyzed. 
These  parts  should  be  broken  down  into  manageable  pieces  and  assigned 
attribute  names  which  are  descriptive  of  the  Ada  parts  they  will 
represent. 

gsiMricjparaiMtara  —  only  if  required 
package  naae  jpkg  ia 
subpregcamjdeolerat lens 
ezoeptlonjdeclasetlons  ; 
end  nasM  jpkg; 

Figure  3.4.  Paekage  Tamplate 

A  common  case  in  translation  templates  is  a  subtemplate  that 
can  be  repeated,  according  to  the  structure  of  the  source  text.  We 
express  such  situations  via  a  naming  convention,  where  the  name  of  a 
slot  containing  repeated  instances  of  a  subtemplate  is  the  plural  form  of 
the  name  of  the  subtemplate.  The  name  of  the  subtemplate  is  always 
singular,  and  the  associated  diagram  represents  a  single  typical  instance 
of  the  subtemplate.  For  example,  the  attribute  {subprogram.declarations} 
name  is  in  the  plural  form  because  a  package  could  have  more  than  one 
subprogram  unit  (see  Figure  3.4). 
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Another  useful  guideline  to  use  when  building  templates  is  to 
use  subtemplates  when  a  portion  of  the  template  is  not  easily  manage¬ 
able.  A  temphite  for  a  Spec  package,  with  the  attribute  names  in  bold 
type,  is  shown  in  Figure  3.4.  The  function  declaration  template,  in  Figure 
3.5,  is  a  subtemplate  for  the  package  template  in  Figure  3.4. 

ganarlcjparaxMtars 

function  name  (  input jparaaatar*  )  return  retum_typ«  ; 

Figure  3.5.  Function  Declarmtion  Template 

The  translation  templates  for  the  future  implementation  of  a 
Spec  MACHINE  are  shown  in  Figures  3.6,  3.7.  and  3.8.  The  procedure 
declaration  subtemplates  shown  in  Figure  3.7  and  Figure  3.8  were  intro¬ 
duced  to  show  the  parameter  structure  and  attribute  names  of  an  Ada 
procedure. 

A  translation  template  for  a  Spec  TYPE  is  given  in  Figure  3.9. 
The  TYPE  template  requires  the  additional  attribute  {type.declaratlons}  to 
build  the  parts  needed  in  Ada  for  coding  abstract  data  types.  The  gener¬ 
ated  type  declaration  in  the  private  part  will  have  an  empty  slot  for  the 
actual  definition  of  the  data  representation  vdiich  must  be  filled  in  during 
implementation.  This  Information  can  also  be  derived  from  a  Spec 
pragma  in  a  future  version  of  the  system. 

The  template  process  is  very  useful  and  should  be  used 
throughout  the  implementation. 
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gttXMtlcjparaawttra 


package  xuuaa  _pkg  is 
aubpsogramjdaelaratlona 
excaptienjdaelaratlona 
end  naaM  _pkg; 


Figure  3.9.  Type  Template 


C.  IBIPLBBAENTATION 

The  purpose  of  attributes  used  in  the  translation  is  to  construct  the 
computed  parts  of  the  desired  Ada  specification.  The  attribute  names 
were  chosen  based  on  the  translation  templates. 

The  reader  should  refer  to  Figures  3.4,  3.5,  3.10,  and  3.11  in  order 
to  understand  the  relationship  between  the  various  tools  used  in  the 
design  and  clarify  any  questions  that  may  arise  from  the  following 
discussion. 

A  sample  production  rule  for  the  non-terminal  “message"  with  sam¬ 
ple  attribute  equations  is  shown  below  in  Figure  3.10.  The  attribute 
names  are  in  bold  type  and  show  how  attribute  values  are  passed  up  the 
parse  tree.  The  attribute  dependency  diagram  shown  in  Figure  3.11 
summarizes  dependencies  between  the  attributes  and  is  discussed  in 
Part  2  of  Section  C. 


message 

:  MESSAGE  £onnal_roessage  response  pragmas 

(  message. foxauljperaMitere  • 

£onnal_message .  £oBMl_paraaeters  ; 

message. retucnjbype  «  respon8e.retum_type; 

message. •sceptlonjdaclaratloas  - 

response. eseeptloajdaclarationa; ) 


Figure  3. 10.  Production  Rule  Attributes 
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ada.spec'cotion 


Figure  3.11.  Attribute  Depeadencj  Diagram 
1.  Attribute  Cbaracteriatlee 

There  are  two  characteristics  used  to  describe  an  attribute.  One 
characteristic  describes  how  the  attribute  is  derived  (s3nntheslzed  or 
inherited)  and  the  other  characteristic  describes  the  attribute’s  data  type. 

An  attribute  is  either  synthesized  or  inherited.  For  synthesized 
attributes,  the  attribute  value  of  the  symbol  on  the  left-hand  side  of  a 
production  is  defined  in  terms  of  the  attributes  of  the  symbols  on  the 
right-hand  side.  Synthesized  attributes  are  computed  bottom-up.  Con¬ 
versely.  inherited  attributes  for  symbols  on  the  right  are  defined  in  terms 
of  the  attributes  of  the  symbol  on  the  left-hand  side.  Inherited  attributes 
are  computed  top-down. 
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The  type  of  an  attribute  refers  to  the  data  type  associated  with 
the  values  of  the  attribute.  The  only  types  allowed  by  Kodlyak  are  Integer, 
string,  and  map. 

For  the  design  presented  here,  all  attributes  are  synthesized 
and  have  values  of  type  string  except  for  the  attribute 
{num_output_variables}.  which  Is  type  integer. 

2.  Attribute  Dependenej  Dlegrem 

The  attribute  dependency  diagram  is  another  useful  tool  for 
understanding  a  design  based  on  an  attribute  grammar.  The  diagram 
shown  In  Figure  3.11,  should  be  constructed  during  the  Implementation 
process.  The  dependency  diagram's  purpose  Is  similar  to  that  for  a  mod¬ 
ule  dependency  diagram  for  a  program  and  shows  which  parts  are 
needed  to  compute  the  value  of  each  attribute. 

Several  pieces  of  information  are  determined  from  analyzing  the 
dependency  diagram.  For  example,  the  attribute  {ada.speclficatlon) 
requires  the  values  of  every  other  attribute  before  its  value  can  be 
determined.  The  diagram  also  shows  uhich  attributes  are  used  more 
than  once  in  the  implementation.  The  diagram  should  prove  extremely 
valuable  for  extending  or  changing  the  implementation  at  a  later  date. 

3.  Attribute  Deflultlona 

The  attribute  dependency  diagram  (Figure  3.11).  the  package 
template  (Figure  3.4),  and  the  function  declarations  template  (Figure  3.5) 
summarize  the  structure  of  the  design.  Each  attribute  is  connected  to  a 
set  of  attributes  on  the  next  lower  level  of  the  diagram.  This  is  the  set  of 
attributes  used  to  define  the  parent  attribute.  For  example,  the  attribute 
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{ada_speclficatlon}  is  defined  in  terms  of  the  attributes 
{generlc_parameters},  (name),  {subprogram^declaratlons},  a  d 
{exception_declarations}.  Hie  following  discussion  is  organized  in  top- 
down  order  with  respect  to  the  attribute  dependency  diagram. 

a.  adajipeciflcation 

The  highest  level  attribute  {ada.speciflcation}  is  used  to 
produce  the  translation  output.  All  of  the  other  attributes  are  built,  con¬ 
catenated  together,  and  stored  in  the  attribute  {ada.8peciflcatlon}.  The 
value  of  the  {ada_specificatlon}  attribute  at  the  root  node  of  the  parse  tree 
provides  the  result  of  the  translation,  as  indicated  by  a  ‘‘%output" 
declaration. 

b.  g€nericj^arajMUr9 

The  attribute  {generlc_parameter8)  is  used  to  build  the 
generic  portion  of  the  package  if  there  is  one.  When  a  package  contains 
generic  parameters,  this  attribute  provides  the  Ada  reserved  words,  vari¬ 
able  names,  type,  and  delimiters  needed  for  the  generic  part  of  an  Ada 
specification. 

c.  nams 

The  attribute  (name)  represents  the  actual  name  of  the 
package,  which  is  *square_root”  for  the  example  shown  in  Figure  3.2.  As 
shown  In  the  package  template  in  Figure  3.4.  the  value  of  an  attribute 
can  be  used  more  than  once.  The  attributes  found  on  the  same  level  as 
{name}  are  the  ones  used  to  build  the  template. 
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d.  subprogramjdeclarations 

The  attribute  {subprogram_declarations}  is  used  to  build 
the  required  subprogram  declaration  statements.  It  uses  the  attribute 
{parameter_name}  and  {parameter_type}  to  build  the  complete  parameter 
list.  This  attribute  also  provides  the  necessary  keywords  for  the  subpro¬ 
gram  declaration  statement. 

e.  exception^declarationM 

The  last  attribute  used  in  the  package  template  is 
{exception^declarations}.  This  attribute  adds  the  exception  declaration 
statements  to  the  Ada  specifications  that  were  found  in  the  MESSAGE. 

/  inputjHuxuMUn 

The  attribute  {lnput.parameters}  provides  the  parameter 
names,  modes,  types,  and  delimiters  for  the  input  parameter  part  of  the 
subprogram  declaration,  for  any  function  or  procedure  that  has  input 
parameters.  The  attribute  (input^parameters)  and  (retum_type}  are 
shown  in  the  function  declaration  template  (Figure  3.5). 

y.  r«turn^typ€ 

The  attribute  (retum.type)  is  used  to  furnish  the  type  of  the 
function’s  return  variable.  An  Ada  function  can  return  only  one  type  per 
Ada  function  and  this  type  may  or  may  not  be  the  same  as  the  type  of 
one  of  the  input  variables. 

h.  outputjtarameUTB 

The  attribute  (output_parameters}  provides  the  parameter 
names,  mode.  type,  and  delimiters  of  the  output  parameter  list  for  an 
Ada  procedure.  This  attribute  uses  {parameter.name}  and 
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{parameter_type}  to  build  the  parameter  list.  The  attribute 
{input  j>arameters}  and  (output_parameters}  are  concatenated  together  to 
form  the  procedure’s  complete  parameter  list. 

i.  num^outputjHuiablea 

The  attribute  {num.output.varlables}  is  used  to  count  the 
number  of  output  variables  in  a  Spec  MESSAGE.  This  is  the  only  attrl- 
bu  3  of  type  Integer  in  the  implementation.  The  number  of  output  vari¬ 
ables  is  important  because  an  Ada  function  can  return  only  one  value. 
After  the  output  var  les  have  b^en  counted,  the  result  is  stored  in 
(num_output.variabh  and  used  .n  a  decision  statement  to  determine 
vdiich  subprogram  declaration  will  be  produced. 

J,  paramtUrjMmB 

The  (parameter.name)  attribute's  purpose  is  to  build  the 
parameter  list  for  the  three  higher-level  attributes  (generiC4>arameters). 
(inpuCparameters),  and  (output.parameters}.  The  {parameter.name} 
attribute  is  not  shown  in  the  package  or  function  declaration  t  plate 
because  it  is  a  lower-level  attribute. 

fc.  poromitUrJtiip^ 

The  attribute  {parameter.type}  is  used  to  provide  the  data 
type  for  all  parameters  in  the  generic,  formal,  and  actual  parameter  lists. 
Also  a  lower-level  attribute,  {parameter.typej  does  not  appear  in  the 
translation  templates. 

I.  %tmct 

The  attribute  {%text}  is  the  lowest-level  attribute  and  is  pre¬ 
defined  by  Kodiyak.  The  value  of  this  attribute  is  the  source  text  that 
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matches  a  terminal  symbol  in  the  grammar.  Every  other  attribute 
depends  on  {%text}  for  pieces  of  actual  text  needed  from  the  initial  Spec 
specification  to  be  used  in  the  output  Ada  specification.  For  example,  the 
names  of  packages,  variables,  and  data  types  are  needed  to  produce  the 
Ada  specification. 

D.  SYSTEM  GENERATION  PROCEDURE 

Once  the  attribute  grammar  has  been  written,  it  must  be  compiled 
using  Kodiyak.  If  compilation  is  successful,  an  executable  **0"  program  is 
produced.  It  is  this  executable  “C"  program  which  accepts  the  Spec  func¬ 
tion  as  input  to  produce  the  Ada  specification.  A  more  detailed  procedure 
for  actually  using  this  implementation  is  explained  in  the  user's  guide 
found  in  Appendix  C. 

E.  SAMPLE  INPUT  AND  OUTPUT 

Several  samples  of  Spec  specifications  used  as  input  for  the  concrete 
interface  generation  system  and  the  respective  Ada  specifications  gener¬ 
ated  by  the  system  are  shown  below.  The  examples  include  cases  of  non- 
generlc,  generic,  multiple  input  values,  multiple  output  values,  exception 
declarations,  and  multiple  exception  declarations,  and  multiple  messages 
are  demonstrated. 

1.  Non'Geneilc  Example 

The  first  example  in  Figure  3,12  shows  a  non-generic  Spec 
FUNCTION  and  the  corresponding  Ada  specification  generated  as  output. 
The  generated  Ada  package  contains  one  function  statement  resulting 
from  the  MESSAGE  and  one  exception  declaration  resulting  from  the 
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OTHERWISE  REPLY  EXCEPTION  statement.  The  Spec  construct 
CONCEPT  does  not  contribute  to  the  Ada  specification  but  does  provide 
information  for  the  package  body,  as  well  as  for  the  test  result  evaluator 
described  in  Reference  12. 

FUNCTION  squar«_root 

MESSAGE (x:  float) 

WHEN  X  >«  0.0 

REPLY (y:  float) 

WHERE  y  >  0.0,  approxinates (y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  linaglnary_square_root 
CONCEPT  approxlmataa (rl  r2:  float) 

VALUE (b:  boolean) 

WHERE  b  <■>  ab8(rl  -  r2)  <•  abs(r2  *  precision) 

END 

A.  Input:  Spec 


pac)cage  square_rootjp)cg  is 

function  nane(x:  in  float)  return  float; 
iinaginary_sq:uare_root :  exception; 
end  square_root_p)tg; 

B.  Output:  Ada  Specification 

ngure  3. 12.  !foii<^nerlc  Binmple 
2.  Generic  Bzample 

A  generic  FUNCTION  was  used  for  the  example  shown  in  Figure 
3.13.  In  this  example,  the  variable  precision  is  generic,  and  the  generic 
parameter  declaration  in  the  Ada  specification  is  generated  from  the  Spec 
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generic  parameter  declaration.  The  rest  of  the  Ada  specification  is  similar 
to  the  non-generic  example  above. 


FUNCTION  square_root (precision: float  SUCH  THAT  precision  >0.0 
MESSAGE (x:  float) 

WHEN  X  >-  0.0 

REPLY (y:  float) 

WHERE  y  >  0.0,  approximates (y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  imaginary_square_root 
CONCEPT  approximates (rl  r2:  float) 

VALUE (b:  boolean) 

WHERE  b  <“>  abs(rl  -  r2)  <■  abs(r2  *  precision) 

END 


A.  Input:  Spec 


generic 

precision:  float; 
pacitage  square^rootjplcg  is 

function  nanva(x:  in  float)  return  float; 
imaginary_8quare_root :  exception; 
end  8quare_root_p)cg; 


B.  Output:  Ada  Specification 


Figure  3.13.  Generic  Example 

3.  Multiple— Mesaagea,  Inputa 

The  example  Spec  FUNCTION  "plus"  shown  in  Figure  3.14 
demonstrates  a  very  Important  feature  of  the  concrete  interface  genera¬ 
tion  system.  A  Spec  FUNCTION  can  contain  more  than  one  MESSAGE 
and  must  generate  a  function  declaration  for  each  instance.  This  is  use¬ 
ful  for  grouping  together  the  overloaded  variants  of  a  fimetion,  especially 
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If  the  meanings  of  the  variants  are  strongly  related.  This  example  also 
demonstrates  the  capability  of  the  concrete  interface  generation  system 
to  generate  the  Ada  specification  for  Spec  inputs  containing  multiple 
parameter  inputs. 


FUNCTION  plus 

MESSAGE (x:inte9«r,  y: integer) 

REPLY ( z : Integer) 

WHERE  z  ■  X  +  y 

MESSAGE (x: reel,  y: Integer) 

REPLY (z: reel) 

WHERE  z  ■  X  +  y 

MESSAGE (x: integer,  y:reel) 

REPLY (z: reel) 

WHERE  z  «  integer_to_reel (x)  +  y 

END 


A.  Input:  Spec 


pac)cege  plus_p)ig  is 

function  name(x:  in  integer;  y:  in  integer)  return  integer; 
function  nenc(x:  in  real;  y:  in  integer)  return  real; 
function  neiaa(x:  in  integer;  y:  in  reel)  return  real; 
end  plus_pkg; 


B.  Output:  Ada  Specification 

Figure  3.14.  Bnmple  of  Multiple  Messages  and  Multiple  Inputs 
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4.  Multiple  Outputs.  Exception  Declsrstions 

TTie  example  in  Figure  3. 15  is  used  to  demonstrate  the  case  of  a 
Spec  FUNCTION  containing  more  than  one  output.  If  a  Spec  FUNCTION 
contains  more  than  one  output,  an  Ada  procedure  statement  is  required. 


FUNCTION  divide 

MESSAGE (x:  integer,  y: integer) 

WHEN  y  —  0 

REPLY (quotient : integer,  remainder : integer) 
WHEN  X-0,  Y-0 

REPLY  EXCEPTION  re3ult_indetenninate 
OTHERWISE  REPLY  EXCEPTION  result_infinite 

END 


A.  Input:  Spec 


package  dividejpkg  is 

procedure  name(x:  in  integer;  y:  in  integer; 

quotient:  out  integer;  remainder:  out  integer); 
result_in£inite:  exception; 
result_indeterminate :  exception; 
end  divide^kg; 


B.  Output:  Ada  Specification 


Figure  3.15.  Example  of  Multiple  Outputs  and 
Multiple  Exception  Declarations 

This  example  includes  multiple  exception  declaration  state¬ 
ments.  As  a  formatting  feature,  when  there  are  multiple  messages,  the 
system  was  designed  to  add  all  exception  declarations  at  the  end  of  the 
Ada  specification  as  a  group. 
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IV.  CONCLUSIONS 


This  thesis  has  shown  the  design  and  implementation  of  a  concrete 
interface  generation  system  is  feasible.  With  the  aid  of  the  concrete  inter¬ 
face  generation  system,  an  Ada  specification  for  the  implemented  subset 
of  Spec  can  be  automatically  generated  in  less  time  than  it  would  take  a 
person  to  enter  a  hand-coded  version  into  the  computer.  A  fully  imple¬ 
mented  concrete  Interface  generation  system  using  Spec  as  the  formal 
specification  language  will  save  many  man-hours  and  greatly  reduce  the 
error  rate  during  the  implementation  phase  of  a  software  development 
project. 

A.  EVALUATION  or  THE  DESIGN 

The  use  of  translation  templates  and  attribute  dependency  diagrams 
proved  to  be  veiy  useful  tools  in  designing  the  concrete  interface  genera¬ 
tor.  To  ensure  success,  the  implementation  had  to  be  approached  in  a 
systematic  fashion.  The  translation  templates  we  ver.  iseful  for  the 
organization  and  naming  of  attributes  before  the  implementatiun  began. 
The  attribute  dependency  diagram  contributed  to  the  design,  during  the 
implementation  process,  by  serving  as  a  quick  reference  for  attribute 
dependency.  Translation  templates  and  attribute  dependency  diagram 
are  both  highly  recommended  for  future  extensions  of  the  concrete  inter¬ 
face  generation  ^tem. 
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B.  EVALUATION  OP  THE  IBlPLEBfENTATION 

The  greatest  impact  on  the  implementation  effort  was  due  to  Kodi- 
yak’s  lack  of  features  and  lack  of  user-friendliness.  The  implementation 
process  could  have  been  much  faster  if  Kodiyak  had  easily  understood 
error  messages,  better  debugging  facilities,  and  a  good  user  interface. 

The  development  of  a  good  user  interface  could  greatly  enhance  the 
use  of  a  tool  like  Kodiyak.  For  example,  a  graphical  interface  with  the 
ability  to  select  attribute  names  from  an  attribute  menu,  display  the 
grammar  in  tree  form,  and  move  about  the  tree  easily  by  selecting  the 
node  to  be  displayed  could  greatly  reduce  the  time  required  to  implement 
a  software  tool. 

Due  to  Kodiyak’s  limited  data  types  and  lack  of  options  to  define 
types  or  constants,  several  features  could  be  added  to  create  a  more 
robust  environment  for  the  generation  of  software  tools.  A  few  features 
that  would  be  helpful  include  the  ability  to  define  symbolic  constants, 
create  user  defined  functions  easily.  Implement  user  defined  data  types, 
and  Interface  with  a  programming  language  like  Ada. 

C.  FUTURE  WORK 

This  thesis  has  shown  the  feasibility  of  creating  and  Implementing  a 
concrete  interface  generation  system.  However,  more  work  must  be  done 
to  implement  the  complete  Spec  language.  The  implementation  of  Spec 
MACHINE  and  TYPE  modules  plus  the  implementation  of  pragmas  for 
MACHINE,  FUNCTION,  and  TYPE  modules  will  be  needed  for  a  complete 
implementation  of  the  concrete  interface  generation  sj^tem. 
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APPENDIX  A 

GRAMMAR  FOR  THE  FORBfAL  LANGUAGE  SPEC 


This  appendix  provides  a  listing  of  the  Spec  grammar  used  in  the 
implementation  of  the  concrete  interface  generation  system. 

start 

:  sp«c 


sp«c 

:  spac  module 

I 

i 

!  A  production  with  nothing  aftar  tha  "I"  maana  tha  empty  string 
!  is  a  legal  replacement  for  the  left  hand  side. 

module 

:  definition 
I  function 
I  type 
I  machine 

I  instance  !  of  a  generic  module 

; 

function 

:  optionally_vlrtual  FUNCTION  module_header  messages  concepts  END 
!  Virtual  modules  are  for  inheritance  only,  never  used  directly. 


machine 

:  optionally^vlrtual  HACHXNE  module^header  state  messages 
temporals  transactions  concepts  END 


type 

:  optionally_virtual  TYPE  module_header  model  messages  teii^ora.is 
transactions  concepts  END 
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definition 

;  DEFINITION  module_header  concepts  END 


instance 

;  INSTANCE  module_header  where  foreach  concepts  END 

9 

!  For  making  instances  or  partial  instantiations  of  generic 

modules . 

.!.  The  foreach  clause  allows  defining  sets  of  instances. 


module_header 

:  formal_name  defaults  inherits  inserts  export  pragmas 

9 

!  This  part  describes  the  static  aspects  of  a  module's 
interface. 

!  The  dynamic  aspects  of  the  interface  are  described  in  the 
messages . 

!  A  module  is  generic  iff  it  has  parameters. 

!  The  parameters  can  be  constrained  by  a  SUCH  THAT  clause. 

!  A  module  can  inherit  the  behavior  of  other  modules. 

!  A  module  can  import  concepts  from  other  modules. 

!  A  module  can  export  concepts  for  use  by  other  modules. 


pragmas 

:  pragmas  PRAGMA  actual^name  ' ( '  actuals  ' ) ' 


inherits 

;  inherits  INHERIT  actualjname  hide  renames 

I 

9 

!  Ancestors  are  generalizations  or  simplified  views  of  a  module 
!  A  module  inherits  all  of  the  behavior  of  its  ancestors. 

!  Hiding  a  message  or  concept  means  it  will  not  be  inherited. 

!  Inherited  components  can  be  renamed  to  avoid  naming  conflicts 
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hide 


;  HIDE  naine_list 
I 
/ 

!  Useful  for  providing  limited  views  of  an  actor. 

!,  Different  user  classes  may  see  different  views  of  a  system. 
!  Messages  and  concepts  can  be  hidden. 

renames 

:  renames  RENAME  NAME  AS  NAME 

I 


!  Renaming  is  useful  for  preventing  NAME  conflicts  when 
inheriting 

!,  from  multiple  sources,  and  for  adapting  modules  for  new  uses. 
!.  The  parameters,  model  and  state  components,  messages, 
exceptions, 

!  and  concepts  of  an  actor  can  be  renamed. 


imports 

:  imports  IMPORT  nam«_list  FROM  actual_name 


export 

:  EXPORT  name  list 


messages 

:  messages  message 


message 

;  MESSAGE  formal^message  pragmas  response 


response 

:  response_8et 
I  response_cases 
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response^cases 

;  WHEN  expression_list  respon3e_set  pragmas  response_case3 
I  OTHERWISE  response_set  pragmas 


response_set 

:  choose  reply  sends  transition 


choose 

:  CHOOSE  ' ( '  formals  ' ) ' 

I 

i 

reply 

:  REPLY  actual_messaga  where 

I  GENERATE  actualjKSSsage  where  !  used  in  generators 


sends 

:  sends  send 

I 

; 

send 

:  SEND  actual^message  TO  ectuel_naaie  where  foreach 

/ 


transition 

:  TRANSITION  expresslon^list  !  for  describing  state  changes 


formaljtnessege 

:  optional_exception  optional_funnal_naine  fonnal_arguments 
defaults 


actual_message 

:  optional_exception  optional_actual_naine  forTnal_arguinents 
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defaults 

;  DEFAULT  expression_list 

I  Iprec  SEMI  !  must  have  a  lower  precedence  than  DEFAUi: 


where 

:  WHERE  expression_list 

I  %prec  SEMI  !.  must  have  a  low  .*  precedence  than  WHERE 


optionally__virtual 
:  VIRTUAL 

I 


opt  i  ona  l_,except  ion 
;  EXCEPTION 
I  %prec  SEMI 

s 

foreach 

;  FOREACH  ' ( '  formals  ' ) ' 


!  foreach  Is  used  to  describe  a  set  of  messages  or  instances 

model  !  data  typ^s  have  conceptual  models  for  values 

:  MODEL  formal_arguinents  invariant  pragmas 


state  !  machines  have  conceptual  models  for  states 

:  STATE  fomal_arguinents  invariant  initially  pragmas 


invariant  !  Invariants  are  true  for  all  states  or  instances 

:  INVARIANT  expression_list 


initially  !  initial  conditions  are  true  only  at  the  beginning 

:  INITIALLY  expression_list 
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temporals 

;  teit^iorals  temporal 


temporal 

:  TEMPORAL  formal_name  defaults  where  response 

f 

!  Ten^oral  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  local  clock  of  the  actor. 

!  The  "where"  describes  the  triggering  conditions 
!,  in  terms  of  TIME,  PERIOD,  and  DELAY. 

transactions 

;  transactions  transaction 


transaction 

:  TRANSACTION  actual_name  action_list  where  foreach 
s 

!  Transactions  are  atomic. 

!  The  where  clause  can  specify  timing  constraints. 
action_list 

:  action_list  ' ; '  action  %prec  SEMI  !  sequence 
I  action 


action 

:  action  action  Iprec  STAR  !  unordered  set  of  actions 
I  IF  alternatives  FI  !.  choice 

I  DO  alternatives  OD  !  repeated  choice 

I  actual_naine  !  a  normal  message  or  subtransaction 
I  EXCEPTION  actual_name  !  an  exception  message 


alternatives 

:  alternatives  OR  guard  action_list 
I  guard  action_list 
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guard 


;  WHEN  expres8ion_list  ARROW 
I 


concepts 

:  concepts  concept 


concept 

:  CONCEPT  formal^nane  ' : '  expression  defaults  where 
!.  constants 

1  CONCEPT  for  ._nawe  ' ( '  formals  ’ ) '  defaults  VALUE  ' { '  f ormals 
') '  where 

!  func  ons,  defined  with  preconditions  and  postconditions 


options  l_f  0  rwa  l_naine 
:  formal  name 


formal^name 

:  NAME  fonnals  '}' 
I  NAME 


f  o  rma  l_a  rgument  s 

:  ' ( '  formals  ' )  ' 

I 


formals 

:  field  list  restriction 


field_list 

:  f ield_li8t  ' , '  type_binding 
I  type_binding 
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type_binding 

:  naine_list  ' : '  expression 
I  '$'  NAME  expression 


name_list 

:  naine_list  NAME 
j  NAME 


restriction 

;  SUCH  expression_list 


optional_actual_name 
:  actual  name 


actual_name 

;  NAME  ' { '  actuals  ' ) ' 

I  NAME  Iprec  SEMI  !  must  have  a  lower  precedence  than  ' ( ' 

» 

actuals 

:  actuals  ' ,  '  arg  %prec  COMMA 
I  arg 


arg 

:  expression 
I  pair 


expression_list 

;  expression_list  ' ,  '  expression  Iprec  COMMA 
I  expression  Iprec  COMMA 
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expression 

:  QUANTIFIER  *  ( '  fontials  BIND  expression  ' )  • 

I  actual__name  !  variables  and  constants 
I  expression  '{'  actuals  ')'  !  function  call 

I  expression  '(*'  actual_name  !  expression  with  explicit  type  cast 
I  NOT  expression  %prec  NOT 
I  expression  AND  expression  %prec  AND 
I  expression  OR  expression  %prec  OR 
I  expression  IMPLIES  expression  %prec  IMPLIES 
I  expression  IFF  expression  %prec  IFF 

I  expression  '<■'  expression  %prec  LE 

I  expression  '<'  expression  %prec  LE 

I  expression  *>'  expression  %prec  LE 

I  expression  LE  expression  Iprec  LE 

I  expression  GE  expression  %prec  LE 

I  expression  NE  expression  Iprec  LE 

I  expression  NLT  expression  Iprec  LE 

I  expression  NGT  expression  Iprec  LE 

I  expression  NLE  expression  Iprec  LE 

I  expression  NGE  expression  Iprec  LE 

I  expression  EQV  expression  Iprec  LE 

I  expression  NEQV  expression  Iprec  LE 

I  expression  Iprec  UMINUS 

I  expression  expression  Iprec  PLUS 

I  expression  expression  Iprec  MINUS 

I  expression  expression  Iprec  MUL 

I  expression  '/'  expression  Iprec  DIV 

I  expression  MOD  expression  Iprec  MOD 

I  expression  EXP  expression  Iprec  EXP 

I  expression  U  -3xpression  Iprec  U 
I  expression  APPEND  expression  Iprec  APPEND 

I  expression  IN  expression  Iprec  IN 
I  expression  Iprec  STAR 

!  *x  is  the  value  of  x  in  the  previous  state 
I  'S'  expression  Iprec  DOT 

!  $x  represents  a  collection  of  items  rather  than  just  one 
!  si  -  (x,  Ss2)  means  si  ■■  union ({x),  s2) 

!  si  •  [x,  $s2]  means  si  *  append ([x],  s2) 

I  expression  RANGE  expression  Iprec  RANGE 

!  X  in  [a  . .  b]  iff  x  in  (a  ..  b)  iff  a  <-  x  <-  b,  [a  . .  b]  is 
sorted  in  increasing  order 

I  expression  ' . '  NAME  Iprec  DOT 
I  expression  '['  expression  ']'  Iprec  DOT 
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I  ' ( '  expression  ' ) ' 

I  expression  NAME  ')'  !  expression  with  units  of 

measurement 

!,  standard  time  units:  NANOSEC  MICROSEC  MILLISEC  SECONDS  MINUTES 
HOURS  DAYS  WEEKS 

I  TIME  !  The  current  local  time,  used  in  temporal 

events 


I  DELAY 


!,  The  time  between  the  triggering  event  and  the 


response 

I  PERIOD  ,!  The  time  between  successive  events  of  this  type 
I  literal  !,  literal  with  optional  type  id 

I  '?'  !  An  undefined  value  to  be  specified  later 

I  ' ! '  !.  An  undefined  and  illegal  value 

I  IF  expression  THEN  expression  iniddle_cases  ELSE  expression  FI 


middle_cases 

:  middle_cases  ELSE_IF  expression  THEN  expression 


literal 

:  INTEGER_LITERAL 
I  REAL^LITERAL 
I  CHAR_LITERAL 
I  STRING_LITERAL 

I  '#'  NAME  !  enumeration  type  literal 

I  ' [ '  expressions  ' ] '  !  sequence  literal 

I  ' ( '  expressions  ' ) '  !  set  literal 

I  ' ( '  formals  BIND  expression  ' } '  !  set  literal 

I  '('  expressions  expression  '}'  !  map  literal 

I  ' [ '  pair_list  ' ] '  !  tuple  literal 

I  '  { '  NAME  BIND  expression  • ) '  !.  union  literal 

0 

!  relation  literals  are  sets  of  tuples 

expressions 

:  expression_list 
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pair_list 

:  pair_list  ' , '  pair 
I  pair 


pair 

:  nanie_list  BIND  expression 
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APPENDIX  B 

KODITAK  SOURCE  CODE  TO  CREATE  THE 
CONCRETE  INTERFACE  GENERATION  SYSTEM- ADACI 


!  version  stamp  SHeader;  src.)t,v  l.i  90/11/03  08:54:59  Rachal  Exp  S 

!  In  the  grammar,  comments  go  from  a  "!"  to  the  end  of  the  line. 

:  Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  ('). 

!  Nor.'w  irminal  symbols  are  entirely  lower  case. 

!  Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  in  ( ) , 
!  In  a  regular  expression,  x-*-  means  one  or  more  x's, 

!  In  a  regular  expression,  x*  means  zero  or  more  x's. 

!  In  a  regular  expression,  (xyz]  means  x  or  y  or  z. 

!  In  a  regular  expression,  [‘'xyz]  means  any  character  except  x  or  y  or  z. 

!  In  a  regular  expression,  [a-z]  means  any  character  between  a  and  z. 

!  In  a  regular  expression,  ,  means  any  character  except  newline, 

!  definitions  of  lexical  classes 


tdefine 

Ideflne 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 

tdefine 


Digit 

Int 

Lower 

Upper 

Letter 

Alpha 

Blank 

Quote 

Backslash 

Char 

Opl 

Op2 

Op3 

Opt 

Op5 

Op 


: (0-9) 

:( Digit)* 

J (s-zj 
: lA-Zl 

:  ( (Lower) I (Upper)) 

:  ((Lower) I (Digit) I 
; (  \t\n] 

:("] 

:  ( [‘'"Wl  I  (Backslash)  (Quote)  I  (Backslash)  { Backslash ) ) 

.  ^  I  I  I  I  I  11  mm'*  I  *(••»>*) 

.  +  (Backslash)  IMODI  "'") 

:  (UIINI".  .-|"l  |-r."l’'[") 

: ((Opl) I (Op2) I (Op3} I (Op4) I (Op5)) 


!  definitions  of  white  apace  and  comments 


: ( Blank ) * 

•  <*.«.•« ,  *'*\n'* 


!  definitions  of  compound  symbols  and  keywords 
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AND 

H  J  M 

OR 

»l  1  It 

NOT 

If  It 

IMPLIES 

**«>** 

IFF 

LE 

GE 

»*>«** 

NE 

<*•>»«** 

NLT 

NGT 

**••>** 

NLE 

NGE 

**  «>  >  a  ^ 

EQV 

itaa** 

NEQV 

•  **<»aa<* 

RANGE 

•  n  ti 

APPEND 

: "  1 1 " 

MOD 

(Backslash) (MOD 

EXP 

•  HAH 

BIND 

•  H  •  «  H 

ARROW 

i"->" 

IF 

IF 

THEN 

;THEN 

ELSE 

lELSE 

IN 

;IN 

0 

;U 

SUCH 

:  SUCH { Blank )*THAT 

ELSE_IF 

:  ELSE (Blank }*IF 

AS 

:AS 

CHOOSE 

:  CHOOSE 

CONCEPT 

:  CONCEPT 

DEFAULT 

;  DEFAULT 

DEFINITION 

:  DEFINITION 

DELAY 

;  DELAY 

DO 

;DO 

END 

:END 

EXCEPTION 

:  EXCEPTION 

EXPORT 

;  EXPORT 

FI 

:FI 

FOREACH 

:  FOREACH 

FROM 

:FROM 

FUNCTION 

•FUNCTION 
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GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 

OF 

OTHERWISE 

PRAGMA 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


: GENERATE 
:HIDE 
: IMPORT 
: INHERIT 
:INITIAILY 
: INSTANCE 
INVARIANT 
:MACHINE 
: MESSAGE 
: MODEL 
:OD 
:OF 

: OTHERWISE 

: PRAGMA 

;PERIOD 

{RENAME 

{REPLY 

{SEND 

{STATE 

{TEMPORAL 

{TIME 

{TO 

{TRANSACTION 

{TRANSITION 

{TYPE 

{VALUE 

{VIRTUAL 

{WHEN 

{WHERE 


QUANTIFIER  {{ Upper )( Upper ) 

NAME  { ( ({Letter) (Alpha)*) I ( (Quote) (Op) (Quote) ) ) 

INTEGER_LITERAL  {(Int) 

REAL_LITERAL  { ( Int )  "  .  "  { Int ) 

CHAR_LITERAL  i« 

STRING  LITERAL  {( Quote ) (Char )*( Quote) 


!  operator  precedences,  lleft  means  2+3*4  Is  (2+3) +4. 


%left 

%left 

%left 

%left 

%left 

%left 

tleft 

%left 


IF,  DO,  EXCEPTION.  NAME,  SEMI; 
' ,  ' ,  COMMA; 

SUCH; 

'8',* 

IFF/ 

IMPLIES; 

OR; 

AND; 
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%left 

NOT; 

%left 

•<*,  •>', 

LE,  GE,  NE,  NLT,  NGT, 

NEQV; 

%left 

IN,  RANGE; 

%laft 

0,  APPEND; 

%laft 

1  4.  t  1  1 

*  0  0 

PLUS, 

MINUS; 

lleft 

MUL, 

DIV,  MOD; 

%laft 

UMINOS; 

%left 

EXP; 

%laft 

■S', 

•  C, 

•{',  dot,  WHERE; 

Haft 

STAR; 

%% 

!Expl«nations  of  attrlbutas. 

!ada_spaclflcatlon  ;  synthaalzad  atrlng  -  tha  raault  of  tha  trantla:ion, 

!ganarlc_paramatars  ;  synthaalzad  string  -  builds  ganarlc  portion  of  an 
!  Ada  spaelflcatlon. 

!nama  :  synthaalzad  string  -  provldas  nama  of  tha  Spac  modula, 

! subprogram_daclaratlons  :  synthaalzad  string  >  builds  subprogram  daclaratlon 
!  statamants  for  functions  or  proeaduras. 

!axcaptlon_daclaratlons  i  synthaalzad  string  -  builds  axcsptlon  daelaratlons 
!  portion  of  an  Ada  pachaga. 

! lnput_paramatars  ;  synthaalzad  string  -  builds  list  of  Input  paramatars  for 
!  tha  function  daclaratlon  statamants. 

!raturn_typa  ;  synthaalzad  string  >  provldas  raturn  typa  of  tha  function. 

!paramatar_nama  synthaalzad  string  -  provldas  paramatar  namas. 

! paramatar_typa  :  synthaalzad  string  -  provldas  data  typa  for  varlablas  In 
!  tha  paramatar  list. 

!output_paramatar3  :  synthaalzad  string  -  builds  list  of  output  paramatars 
!  for  tha  procadura  daclaratlon  statamants. 

! num_output_varlablas  :  synthaalzad  Intagar  -  provldas  an  Intagar  valua 
!  usad  by  tha  daclslon  statamant  In  tha  massaga 

!  production  to  declda  which  subprogram  daclaratlon 

!.  statamant  Is  raqulrad. 
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!%text  :  synthesized  string  -  a  Kodiyak  pre-defined  attribute  initialized 

!  the  text  the  terminal  symbol  matched. 

! Attribute  declarations, 

start!  ada_specification: string;  ); 

spec!  ada_specif ication : string;  ); 

module ! ada_specif ication : string;  ) ; 

function !  ada_specif ication : string; 

generic_paramaters : string; 
subprogr am_declarat ion  s : string; 
except ion_declarations: string; 
name; string;  ); 

module_header !  name; string; 

generic_parameters; string;  ); 

messages !  input_parameters ; string; 
return_typa;string; 
subprogram_declarations; string; 
except ion_declarat ions ; St ring;  ); 

message!  input_parameters ; string; 
return_type; string; 
subprogram.deelarations; string; 
output_parameter s ; string; 
num_output_varlables;int; 
exceptlon_declarations ; string;  }; 

response!  return_type; string; 

output_parameters ; string; 
num_output_var lables : Int ; 
except ion_declarat ions : st ring;  ) ; 

response_cases !  return_type ; string; 

outputjjarameters ;string; 
num_output_variables ;int; 
exception_declarations ; string;  ) ; 

response_set !  return_type ; string; 

output_parameters : string; 
num_output_var iables ; int; 
exceptlon_declarations ; string;  ) ; 
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reply {  return_type:string; 

output_parameters:strlng; 
num_output_variables :int; 
except lon_declaratlons : string;  ) ; 

formal_message(  input_paranieters : string;  ); 

act ual_mes sage {  return_typa : string; 

output_parameters! string; 
num_output_variables  tint; 
excaption_declarations:string;  ) ; 

formal_name(  nametstring; 

generic  -ameters: string; 
ttext ;  St  ;  ) ; 

formal_arguinents (  input  ^parameter a : string; 

output_parameters : string; 
num_output_variables : int; 
return_type! string;  ); 

formal! {  input_parametars ; string; 

output_parametert: string; 
generlcj>arameter • : string; 
num_output_var iables  s int ; 
return_type: string;  ); 

f ield_list (  input_parameter s : string; 

output_parametars: string; 
goneric_parametars; string; 
num_o-.-  •._var iables  tint; 
return^  oe: string; 

type_binding(  input_parameters : string; 

output_parameter s : st  ring; 
gencrlc_paraneters : string; 
parafflatar_namo : string; 
paramater_type ; string; 
return_type; string;  ); 

name_list (  par affieter_nane: string; 

%text: string;  ); 

optional_actual_name(  exception_declarations : string;  ); 
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actual_name(  pararaeter_type! string; 

return_type:string; 
exception_declarations : string; 
%t«xt : string;  ); 

expression!  parameter_typa: string; 

return_type; string;  }; 

EXCEPTION!  %text: string;  ); 

QUANTIFIER!  %text ! string;  ); 

NAME!  Itext: string;  >; 

INTEGER_LITERAL!  Itext : string; ) ; 

REAI<_LITERAL(  Itext :  string;  ); 

CHAR_LITERAL(  Itext : string;  ); 

STRIMG_LITERAL!  Itext : String;  )i 

II 

!  productions  ot  the  granunar 


start 

;  spec 

{  loutput (spee.ada^speelflcatlon) ;  ) 


spec 


spec  module 

!  spec  [1]  .acla_specification  > 

(spec[2] .ada_specificatlon, module. ada_specificationi ;  ) 

!  spec. ada_specificat ion  •  ) 


!  A  production  with  nothing  after  the  ”1"  means  the  empty  string 
!  is  a  legal  replacement  for  the  left  hand  side. 


module 

:  definition 
{  } 

I  function 

!  module. ada_speclfication  -  function. ada_specif icatxon; ) 
I  type 
!  ) 
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I  machine 
{  ) 

I  instance  !  of  a  generic  module 

(  ) 


function 

:  optionally_virtual  FUNCTION  module_header  messages  concepts  END 
(  function .ada_specification  » 

(module_header .generic_parameters, 

"package  ",  module_header .name,  "_pkg  is\n", 
messages . subprogram_declarations , 
messages. except ion_declarat ions, 

"end  ",  module_header,name,  "_pkg;\n\n"l ;  ) 

$ 

!  Virtual  modules  are  for  inheritance  only,  never  used  directly. 


machine 


optionally_virtual  MACHINE  module_header  state  massages  temporals 

transactions  concepts  END 


(  ) 


type 


:  optionally_virtual  TYPE  module_header  model  messages  temporals 

transactions  concepts  END 


(  ) 


/ 


definition 

:  DEFINITION  module_haader  concepts  END 

(  ) 


instance 

:  INSTANCE  module_header  where  foreach  concepts  END 

(  ) 

; 

!  For  making  instances  or  partial  instantiations  of  generic  modules. 

!  The  foreach  clause  allows  defining  sets  of  Instances. 

module_header 

forfflal_nanie  defaults  inherits  imports  export  pragmas 
{  module_header .name  -  formal_name.name; 

modulo_header .generic_parameters  »  formal_name .generic_parameters; ) 
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!  This  part  describes  the  static  aspects  of  a  module's  interface. 

!  The  dynamic  aspects  of  the  interface  are  described  in  the  messages 

!  A  module  is  generic  iff  it  has_parameters . 

!  The_parameters  can  be  constrained  by  a  SUCH  THAT  clause. 

!  A  module  can  inherit  the  behavior  of  other  modules.; 

!  A  module  can  import  concepts  from  other  modules. 

!  A  module  can  export  concepts  for  use  by  other  modules. 

pragmas 

:  pragmas  PRAGMA  actual_name  •('  actuals  ')' 

(  ) 

I 

{  ) 

0 

inherits 

;  inherits  INHERIT  actual_name  hide  renames 

(  ) 

I 

(  ) 

0 

!  Ancestors  are  generalizations  or  simplified  views  of  a  module., 

!  A  module  inherits  all  of  the  behavior  of  its  ancestors. 

!  Hiding  a  message  or  concept  means  it  will  not  bo  inherited. 

!  Inherited  components  can  be  renamed  to  avoid  naming  conflicts., 

hide 

!  .HIDE  name_list 

I  ) 

1 

{  ) 

0 

!  Useful  for  providing  limited  views  of  an  actor. 

!  Different  user  classes  may  see  different  views  of  a  system.; 

!  Messages  and  concepts  can  be  hidden. 

renames 

;  renames  RENAME  NAME  AS  NAME 

{  ) 

I 

(  ) 


!  Renaming  is  useful  for  preventing  NAME  conflicts  when  inheriting 
!  from  multiple  sources,  and  for  adapting  modules  for  new  uses. 

'  The_parameters,  model  and  state  components,  messages,  exceptions, 
!  and  concepts  of  an  actor  can  be  renamed. 


61 


imports 


imports  IMPORT  name_list  FROM  actual_name 
(  1 

i 

{  ) 


•Xpert 

:  EXPORT  nam«_list 
{  ) 

I 

(  ) 


massages 

;  massages  massage 

(  massages ( 1] .subprogram_daclarations  • 

(massages [2 ] . subprogram_claclarations, 
nassaga, subprogram_daclarations] ; 
massagasdl  .•xcaption_daclarations  ■ 

[masaagas[2 ) ,axcaption_declarations, 
massage. •xcaption_daclaratlons ) ;  ) 

I 

{  massages. subprogram^daclaratlons  <■ 

massages. •xeaption_daclaratlons  >  ) 

t 


massage 

:  MESSAGE  formal_massaga  response  pragmas 
(  massage. subprogram_daclaratlons  •• 

response.. ’:.um_output_variablas  1 

->  extfunction  nameC,  formai_message.input_parameters, 

")  return  ",  response. return_type,  ";\n"l 
#  ("Xtprocedure  name(", formal_message.input_parameters, 
";XnXtXtXt",  response. output_parameters,  ");Xn"]; 
message. •xception_declarations  •  response. exception_declarations; ) 
t 

response 

:  response_set 

{  response. return_type  -  response_set.return_type; 

response. output_paraffleters  ••  response_set.output_parameters; 
response .num_output_varlables  •  response_set .num_output_variables; 
response. exception_deciarations  »  } 

I  response_cases 

(  response. return_type  •  responso  cases.return_type; 
response. output_parameters  > 
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response_cases . output_par ameters ; 
response. num_output__variable9  » 

response_cases . num_output_var lables ; 
response. except ion_declarat ions  * 

response_ca9es. except ion_declarat ions;  ) 


response_cases 

WHEN  expres9ion_list  response_set  pragmas  response_cases 
(  response_case9[ll .return_typa  - 

[response_casas [2] .return_type,  response_set.return_type] ; 
responsa_cases [1] .exception_declarationa  > 

[response_caaes [2] .exception_declarations, 
rasponsa_set .exceptiondeclarations ] ; 
response_cases [1] .output_parameters  » 

[rasponse_cases (2 ] .output_parameters, 
response_set .output_paraffleters]; 
rasponsa_caaea[l] .num_output_variables  • 
responie_aet .num_output_variable9;  ) 

I  OTHERWISE  response^set 

(  retponse_cases [1] .exception_declarations  « 
rasponse_set . except ion_deciar at ions; 
response_cases.num_output_variables  <• 
response_set .num_output_variables; 
retponse_cases.return_type  ■ 
response_cases .output_parameters  - 


re9pon$e_9et 

;  choose  reply  sends  transition 

(  rasponse_set .return_type  -  reply. return_type; 

response_set.output_parameters  -  reply. output_parameter9; 
response_set . nuin_output_variables  •  reply . num_output_variables ; 
rasponse_set .exception_declaratlons  » 
reply. exception_declaratlons;  ) 


choose 

!  CHOOSE  '  ( '  formals  • )  ' 
{  ) 


{  ) 


reply 

:  REPLY  actual_message  where 

(  reply. r6turn_type  »  actual_me9sage.return_type; 

reply .output_parameters  »  actual_message.output_parameters; 
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reply . num_output_var lable*  -  actual_message . num_output_var lables ; 
reply .exception_declatations  - 

actual_message.exception_declarations;  ) 

I  GENERATE  actual_message  where  !  used  in  generators 

(  } 

I 

(  reply. return_type  » 

reply .output_parameters  - 

reply. exceptlon_declaracions  -  ) 

sends 

:  sends  send 
{  ) 

I 

(  ) 
s 

send 

:  SEND  actual_message  TO  actual_naiiie  where  foreach 
{  > 


transition 

:  TRANSITION  expresslon_llst  !  for  describing  state  changes 

(  ) 

I 

(  ) 

; 

f ormal_massage 

:  optlonal_exceptlon  optlonal_formal_name  forma.  jments  defaults 
(  formal_raessage.lnput_parameters  - 

formal_argufflents . lnput_parameters;  ’ 


actual_massage 

:  optlonal_exceptlon  optlonal_actual_name  formal_arguments 
(  actual_message.return_type  »  formal_arguments.return_type; 
actual_message.output_parameters  - 

forfflal_arguments . output_parameters; 
act ual_mes sage. num_output_varlables  - 

forfflal_arguments.num_output_varlables; 
act ual_message. except lon_declaratlons  • 

opt lonal_actual_name. except lon_declarat Ions;  ) 
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defaults 


:  DEFAULT  expression_list 
{  ) 

1  Iprec  SEMI  !  must  have  a  lower  precedence  than  DEFAULT 

{  ) 


where 

WHERE  expression_list 

{  ) 

I  Iprec  SEMI  !  must  have  a  lower  precedence  than  WHERE 

(  ) 


optionally_virtual 
:  VIRTUAL 
(  ) 

I 

(  ) 


optional_excaption 
;  EXCEPTION 
{  ) 

I  Iprec  SEMI 

(  ) 


f oreach 

:  FOREACH  '  ( '  forraals  ' )  ' 

(  } 

I 

(  ) 

/ 

!  foreach  is  used  to  describe  a  set  of  messages  or  instances 

model  !  data  types  have  conceptual  models  for  values 

:  MODEL  formal_arguments  invariant  pragmas 
{  ) 

I 

(  ) 
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state 


!  machines  have  conceptual  models  for  states 
:  STATE  formal_arguments  invariant  initially  pragmas 
(  ) 

I 

(  ) 


invariant  !  invariants  are  true  for  all  states  or  instances 

:  INVARIANT  expression_llst 
(  ) 


initially  !  initial  conditions  are  true  only  at  the  beginning 

:  INITIALLY  expression_liat 
(  ) 


temporals 

;  temporals  temporal 
{  } 


(  ) 


temporal 

:  TEMPORAL  formal_name  defaults  where  response 

(  ) 

/ 

!  Temporal  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  local  clock  of  the  actor. 

'  "ne  "where"  describes  the  triggering  conditions 
!  terms  of  TIME,  PERIOD,  and  DELAY. 


transactions 

:  transactions  transaction 
(  ) 

I 

(  } 


transaction 

!  TRANSACTION  actual_name  action_list  where  foreach 

(  ) 

/ 

!  Transactions  are  atomic. 

!  The  where  clause  can  specify  timing  constraints. 
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action_list 

:  action_list  ' ; '  action  %prec  SEMI  !  sequence 
(  ) 

I  action 
{  ) 


action 

:  action  action  %prec  STAR  !  unordered  set  of  actions 
{  ) 

I  IF  alternatives  FI  !  choice 
(  ) 

I  DO  alternatives  OD  !  repeated  choice 
(  ) 

I  actual_name  !  a  normal  message  or  subtransaction 
(  ) 

I  EXCEPTION  actual_name  !  an  exception  message 
{  ) 


alternatives 

;  alternatives  OR  guard  action_list 
(  ) 

I  guard  action_list 
(  ) 


guard 

!,  WHEN  axpression_list  ARROW 

{  ) 

1 

{  } 
t 

concepts 

:  concepts  concept 
(  ) 

I 

(  ) 


concept 

:  CONCEPT  formal_name  ' : '  expression  defaults  where 
!  constants 
(  ) 

I  CONCEPT  formal_name  '('  formals  ')'  defaults 

VALUE  '('  formals  ')'  where 
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!  functions,  defined  with  preconditions  and  postconditions 
(  ) 


optional_f ormal_name 

:  formal_name 

(  } 

I 

{  ) 


f otmal_name 

:  NAME  •  { '  formals  ' )  • 

<  formal_name.name  ••  NAME.%taxt; 

formal_name.qaneric_parameters  •  I"genetic\n\t", 
formals. generic_parameters,  ";\n"l;  ) 

I  NAME 

(  formal_name.name  -  NAME.%text; 

forfflal_name.q(enarle_parameters  -  ) 

; 

formal_ar9uments 

:  ' ( '  formals  ' ) ' 

(  formal_arguments .input_parameters  ■  formals . input_param#ters, • 

formal_ar9uments.output_paraffletars  •  formals,output_parameters; 
formal_ar9um«nta .num_output_variablas  > 
formals .num_output_variables; 
formal_arguments.return_typ«  ■  formals. raturn_type;  ) 

I 

{  formal_argumants . input_parameters  « 
formal_ar9uments.output_paramsters  - 
formal_arguments.return_type  -  ) 

formals 

:  field_list  restriction 

{  formals. input_parameters  >  field_list.input_parameters; 

formals. output_parameters  -  field_list.output_parameters; 
formals .generlc_parameters  -  fi9ld_list.generic_parameters; 
formals .num_output_varlable9  -  f i0ld_list . num_output_variables; 
formals. return_type  ■  fleld_list.return_type;  ) 
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£ield_list 

;  fieldi_list  type_binding 

{  field_list (1) .input_parametets  - 

[field_list  [2]  •.input_patametars,  ", 
type_binding . input_parameters 1 ; 
field_list [1] .generic_parameters  - 

[field_list [2] .generic_parameters,  ", 
typa_binding . genar ic_parameter9 1 ; 
field_list[ll .output_paramatar9  - 

[field_llst (21 .output_parameter9,  ";  ", 
type_bindlng , output_parameter s ] ; 
f ield_list [ 1 ] . num_output_variables  - 

field_list [2] .num_output_variabla9  +  1; 
fiald_li9t [1] .raturn_typa  «  typa_binding. return_type;  ) 

I  type_blnding 

(  f iald_list . input_parametar9  •  typa_binding.input_parameters; 

£lald_liit.output_parametar9  -  typa_binding.output_parameters; 
£lald_list ,ganaric_paramatar9  •  type_binding, generic_parameters; 
f iald^list . num_output_variablaa  ■  1; 
f iald_li*t . raturn_typa  «  typa_blnding.raturn_type;  ) 


typa_binding 

:  nama_list  '  : '  axprasslon 

{  typa_blndlng. lnput_paramatar«  ■ 

(nama_list .paramatar_nania,  in  ", 

axprasslon. pacamacar^typa) ; 
typa_blnding,ganarlc_paramatara  - 
(nama_ii3t .paramatar_nania,  ", 

expression  .par ainatar_typa} ; 
type_binding.output_parameter9  • 

[name_list .paranieter_name,  out  ", 

expression .par ameter_typa) ; 
type_bindlng.raturn_type  -  expression. return_typa;  } 
I  '$'  NAME  expression 
{  ) 


name_list 

;  natRe_list  NAME 

(  nanie_llst  [1]  .parameter_name  •  [name_list  [2  1  .parameter_name,  " 
NAME.Itext] ;  ) 

I  NAME 

{  name__list  .parameter_name  »  NAME.ttext;  } 
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restriction 


:  SUCH  expression_list 

(  > 

I 

(  ) 


optional_actual_name 
:  actual_name 

{  optional_actual_name.exception_decl*tationi  « 

["\t", act ual_name.exception_cleclatat ions,  "  :  exception;  \n"  1 

I 

(  optional_actual_name.exception_declarations  -  ) 


actual_nam« 

:  NAME  ' { '  actuals  ■ ) ' 

(  ) 

I  NAME  %prec  SEMI  I  mutt  have  a  lower  precedence  than  '  ( ' 

(actual_nama.paraffleter_type  •  NAME.%text; 
aotual_name.return_type  <•  NAME.Itext; 

actual_name.exceptlon_declaratlont  -  NAME.%text;  > 

! 

actuals 

;  actuals  ai9  tprec  COMMA 
{  ) 

I  arg 

{  ) 


arg 

;  expression 
(  ) 

I  pair 
(  ) 


expres9ion_list 

:  expression_list  expression  %prec  COMMA 
{  ) 

I  expression  %prec  COMMA 

{  ) 


70 


expression 

:  QUANTIFIER  '('  formals  BIND  expression  ')' 

(  ) 

I  accual_name  !  variables  and  constants 

t  expression .parameter_type  »  actual_name.parameter_type; 
expression. return_type  «  actual_name, return_cype; 


I  expression  '('  actuals  !  function  call 

(  ) 

I  expression  '0'  actual_name  !  expression  with  explicit  type  cast 

{  ) 

I  NOT  expression  tprec  NOT 

{  ) 

I  expression  AND  expression  %prec  AND 

(  ) 

I  expression  OR  expression  %prec  OR 

{  ) 

I  expression  IMPLIES  expression  %prec  IMPLIES 

(  ) 

I  expression  IFF  expression  %prec  IFF 

{  ) 

I  expression  '<•'  expression  tprec  LE 

(  ) 

I  expression  '<'  expression  Iprec  LE 

{  ) 

I  expression  '>'  expression  tprec  LE 

(  ) 

I  expression  LE  expression  tprec  LE 

(  ) 

I  expression  GE  expression  tprec  LE 

(  ) 

I  expression  NE  expression  tprec  LE 

(  ) 

I  expression  NLT  expression  tprec  LE 

(  ) 

i  expression  NGT  expression  tprec  LE 

(  ) 

I  expression  NLE  expression  tprec  LE 

(  ) 

I  expression  NGE  expression  tprec  LE 

(  ) 

I  expression  EQV  expression  tprec  LE 

(  } 

I  expression  NEQV  expression  tprec  LE 

{  ) 

I  expression  tprec  UMINUS 

(  } 


71 


expression 

(  ) 

expression 

{  ) 

expression 

(  ) 

expression 

/  1 

*  +  » 

expression 

%prec 

PLUS 

(  «  1 

expression 

%prec 

MINUS 

t  *  t 

expression 

%prec 

MUL 

'/' 

expression 

%prec 

DIV 

\  f 

expression 

/  V 

MOD 

expression 

%prec 

MOD 

V  I 

expression 

{  ) 

expression 

(  } 

expression 

(  ) 

axprasslon 

EXP 

expression 

%prec 

EXP 

U  axprasslon  %prec 

APPEND  expression 

U 

%prec 

APPEND 

IN 

expression 

%prac 

IN 

(  } 

I  axprcasion  %pr«c  STAR 

!  *x  li  th«  valu*  of  x  in  th*  provlout  stat* 

(  > 

I  oxprossion  %prac  DOT 

!  $x  ropraaanta  a  collactlon  of  Itama  rathar  than  just  ona 
!  si  -  (X,  $s2)  maans  si  >  unlon((x),  s2) 

!  si  ••  [X,  $s2)  maans  si  -  appand((x],  s2) 

(  ) 

I  axprasslon  RANGE  axprasslon  %prae  RANGE 

!  X  in  [a  ..  b]  Iff  X  In  (a  ..  b)  iff  a  <■  x  <>  b,  [a  ..  b]  Is 
!  sortad  In  Incraaslng  ordar 

(  ) 

I  axprasslon  ' . '  NAME  %prac  DOT 

(  ) 

I  axprasslon  '['  axprassion_llst  *prac  DOT 

(  ) 

I  ' ( '  axprasslon  ' ) ' 

{  ) 

I  '('  axprasslon  NAME  ')  '  !  axprasslon  with  units  of  maasuremant 

!.  standard  tlma  units;  NANOSEC  MICROSEC  MILLISEC  SECONDS  MINUTES 
!  HOURS  DAYS  WEEKS 

(  ) 

I  TIME  !  The  currant  local  tlma,  used  In  temporal  events 

{  ) 

I  DELAY  !  The  time  between  the  triggering  event  and 

!  the  response 

(  ) 

I  PERIOD  !  The  time  between  successive  events  of  this  type 

(  ) 
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middl*_cas«s 

;  mlddl«_cas«f  £LSE_IF  •xprastion  THEN  axprasaion 

(  > 

I 

{  ) 


literal 

!  INTEGER_LITERM 
{  ) 

I  RrRl_LITERAL 

{  ) 

I  CHAR_LITERAl, 

(  ) 

I  STRINa_LITERAL 

(  ) 

>  *'  NAME  !  enumeration  type  literal 

(  ) 

I  ' [ '  expresslona  ' ] '  !  sequence  literal 

(  ) 

I  '('  expressions  !  set  literal 

(  ) 

I  '('  formals  BIND  expression  ')'  !  set  literal 

(  ) 

I  '('  expressions  expression  ’)'  !  map  literal 

(  ) 

I  't'  pair_list  !  tuple  literal 

(  ) 

I  '{'  NAME  BIND  expression  !  union  literal 

(  ) 

} 

!  relation  literals  are  sets  of  tuples 

expressions 

:  expresslon_llst 

(  ) 
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pair_llst 


{  ) 


:  pair_list  pair 
(  ) 

I  pair 
{  ) 


pair 


nam«_liit  BIND  axpraation 
(  ) 

I 
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APPENDIX  C 

ADACI  USER'S  GUIDE 


A.  INTRODUCTION 

The  purpose  of  this  user’s  guide  is  to  enable  a  user  to  generate  an 
Ada  specification  from  a  valid  Spec  specification  via  the  concrete 
interface  generation  system.  This  guide  assumes  an  executable  version 
of  the  concrete  Interface  generation  system  hr.s  been  installed  on  your 
system.  The  user's  guide  also  assumes  the  reader  is  familiar  with  Spec 
and  Ada. 

B.  SPEC  INPUT 

The  user  must  provide  a  valid  Spec  input  file  for  the  concrete 
interface  generation  system. 

The  concrete  interface  generation  system  has  not  been  fully 
implemented.  For  the  current  version  of  the  system,  "valid  Spec 
input"  is  a  file  containing  one  Spec  FUNCTION  module.  The  current 
version  ignores  the  following  non-terminals  and  their  productions: 

•  types 

•  machines 

•  definitions 

•  pragmas 

•  inherits 

•  hide 
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•  renames 


•  imports 

•  export 

C.  GETTING  STARTED 

Make  sure  that  the  command  “adacl”  is  in  your  name  space  by 
entering  the  command  “which  adaci"  at  the  UNIX  prompt.  If  it 
responds  with  a  pathname,  you  are  ready  to  use  the  system. 

If  you  get  an  error  message  that  starts  with  “no  adaci  in  you 
should  edit  your  .cshrc  fUe  to  add  the  path  for  the  Spec  tools  to  the 
path  variable  in  your  unix  shell.  On  suns2,  this  path  should  be 
“/usr/spectools“  and  the  line  added  to  your  .cshrc  file  should  look  like 
the  following: 

set  path  •  ($path  /usr/spectools) 

D.  SYSTEM  OPERATION 

Operation  of  the  concrete  interface  generation  system  is  very 
simple.  Place  the  file  containing  a  valid  Spec  specification  in  a  file 
named  “spec_flle_name"  in  your  current  working  directory.  From  the 
UNIX  prompt,  enter  the  command: 

adaci  spcc.flle.name  >  ada_flle_naine 

The  concrete  interface  generation  system  will  store  the  generated 
Ada  specification  in  the  file  “ada_file_name."  The  Ada  specification 
will  be  displayed  on  the  terminal  screen  if  the  “>  ada.flle_name”  is 
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omitted.  The  command  adaci  can  also  be  used  as  a  filter  in  a  UNIX 
pipe. 

B.  SABIPLE  EXECUTION 

To  generate  the  Ada  specification  for  the  Spec  FUNCTION 
"square.root"  using  the  concrete  interface  generation  system,  follow 
these  steps. 

1.  Store  the  Spec  FUNCTION  “square_root"  shown  in  Figure  C.l  in 
a  file  named  “sqrt.s". 


FUNCTION  8quare_root{ precision: float  SUCH  THAT  precision  >0.0 
MESSAGE (x:  float) 

WHEN  X  >-  0.0 

REPLY (y:  float) 

WHERE  y  >  0.0,  approximates (y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  imaginary_square_root 
CONCEPT  approximates (rl  r2:  float) 

VALUE (b:  boolean) 

WHERE  b  <■>  abs(rl  -  r2)  <*  abs(r2  *  precision) 

END 


Figure  C.l.  Generic  Example,  Input:  Spec 


2.  At  the  UNIX  prompt  enter  the  command: 


adaci  aqrt.a  >  aqrt.a.a 


3.  At  the  UNIX  prompt  enter  the  command:  more  aqrt.a.a 

4.  The  Ada  specification  of  Figure  C-2  will  be  displayed  on  the  ter¬ 
minal  screen. 
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generic 


precision:  float; 
package  sq:uare_root_pkg  is 

function  name(x:  in  float)  return  float; 
iinaginary_square_root :  exception; 
end  square_rootjpkg; 

Figure  C.2.  Generic  Bzemple,  Output:  Ada  Specification 
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